Summary

  • Agile Software should be judged by the accepted product-change record: whether an engineering or manufacturing change keeps item revision, BOM, AML, supplier, compliance, attachment, workflow and implementation context intact after approval.
  • The economics are favorable only when fewer product-data errors, cleaner audit evidence and downstream manufacturing control exceed the cost of licensing, administration, integrations, migration planning, specialist support and legacy lifecycle exposure.

The Change Record Is The Product

Agile Software is an easy name to misunderstand. The relevant subject is not agile software development, nor a general claim that manufacturers should move faster. It is the Agile Software Corporation product lifecycle management lineage that Oracle acquired in 2007 and that many manufacturers know as Oracle Agile PLM. Its operating promise sits in a narrower place than the broad PLM label suggests: a product change can be proposed, reviewed, approved, released and then trusted as the accepted record for the product.

That sounds administrative until a physical product is involved. A product change is not just a decision. It is a bundle of dependent facts. A part number may change. A component quantity may change. A manufacturer part may be replaced. A document may be revised. A site may need a different effectivity date. A supplier declaration may be stale. A compliance rule may be tied to a material that sits several levels below the visible assembly. A downstream manufacturing system may need a clean implementation signal rather than an email from engineering.

The cost of losing one of those links is not measured only in the time it takes to correct a form. It can show up as scrap, a build hold, rework, missed launch timing, a supplier dispute, a quality escape or a regulatory question that no one can answer quickly.

This is why Agile PLM is best judged by the accepted product-change record. Category breadth is not enough. A PLM suite may contain portfolio, collaboration, cost, quality and compliance modules. Those categories matter, but they do not prove that a single engineering change order can move from proposal to accepted lifecycle record without losing its bill of material, approved manufacturer list, supplier evidence, workflow history, attachments, effectivity logic and downstream implementation state.

The real test is whether the record remains usable after the meeting is over and after the people who remember the decision have moved to another project.

Agile's historical strength was that it treated product data as controlled business data, not as a collection of drawings and spreadsheets around the edge of ERP. Oracle's own Agile PLM documentation describes engineering change orders that create new trackable item revisions; manufacturer change orders that affect manufacturer data without necessarily changing item revision; and site change orders that handle site-specific BOM and AML information. The same documentation describes workflow status, approvers, observers, acknowledgers, attachments, history and redlining. Those are not decorative features.

They are the anatomy of a change that has to survive handoffs across engineering, sourcing, manufacturing, quality and compliance.

The product-change record also creates the sharpest commercial question. Agile PLM is worthwhile when the accepted record reduces ambiguity more than it adds operating burden. If it becomes the place where item masters, BOMs, manufacturer data, compliance declarations and approvals converge, then it can reduce the hidden cost of product-data error. If it becomes a slow record-keeping layer that teams bypass with spreadsheets, shared drives and informal approval trails, the same system can become a tax on the work it was meant to control. The value is not in having a PLM system.

The value is in having a change record that the company can trust.

What Agile PLM Has To Preserve

The first thing Agile PLM must preserve is item and revision truth. In manufacturing, the item record is not only a name and description. It is the controlled reference point for the product structure, documents, manufacturer parts, lifecycle phase and history attached to that part or assembly. A change order that releases a new item or modifies a released item must distinguish between the current released revision, a pending revision and the revision that downstream users should act on after release. If users cannot tell which revision is current, or if the revision in ERP differs from the revision in PLM, the product record loses authority.

The second thing it must preserve is BOM truth. A bill of material is a hierarchy, but the practical problem is not just hierarchy display. A change may add a component, remove one, replace one, alter quantity, change reference designators or affect only a site-specific portion of the structure. Agile PLM's redlining model matters because users need to see not only the final state but the difference between the current released structure and the proposed one.

A change that says "replace component" is weak if it does not show where the component sits, what quantity changes, which assembly revision is affected, whether the change is common or site-specific and what downstream systems have received.

The third thing is manufacturer and supplier context. Many production problems begin when an engineering part number looks clean while the approved manufacturer list around it is stale. An MCO can be more important than an ECO when the design does not change but the source of supply does. If a manufacturer part becomes obsolete, restricted, out of allocation or unsuitable for a site, the accepted product-change record needs to carry that context. A PLM system that controls design revisions but leaves approved manufacturer data to procurement spreadsheets will not protect the product record at the point where supply risk enters the build.

The fourth thing is compliance evidence. Agile Product Governance and Compliance was designed to collect and analyze regulated substance and supplier declaration data, including material declarations and supporting documentation. That is not just a separate compliance workload. It is part of product-change quality. If a change swaps a manufacturer part or alters an assembly, the accepted record needs to show whether the compliance basis still holds.

A product that is technically buildable but has weak evidence for RoHS, hazardous substance, medical device, environmental or customer-specific compliance requirements is not a clean accepted record. It is a risk waiting for the next audit, customer questionnaire or market restriction.

The fifth thing is approval evidence. A change record must show who reviewed it, what role they played, what status the workflow reached and whether the signoff process was strong enough for the business context. Agile PLM's workflow model lets administrators define statuses and routing behavior, while related documentation also shows how password requirements and dual identification can become part of approval signoff configuration. The operational point is simple: approval is not only "yes" or "no." It is an accountable event.

In regulated or high-consequence manufacturing, a weak approval trail can be as damaging as a wrong part number.

The sixth thing is implementation context. A change that is accepted inside PLM but not understood by manufacturing, planning, purchasing or service is incomplete. Oracle's Agile-to-E-Business integration material describes change release as a trigger that can generate Agile XML, transform data, post change-order information to ERP and communicate implementation status back to Agile PLM. That is the right shape of the problem. The PLM record is strongest when release does not end in a human retyping exercise.

But the same integration material also reveals the burden: data must be filtered, parsed, mapped, sequenced, checked for item existence and reconciled with the destination system's model. The accepted record depends on integration fidelity, not simply on an export button.

These six domains make the product boundary clearer. Agile PLM is not valuable because it can host many entities. It is valuable when those entities converge around a change that a manufacturer can safely act on. If the BOM, AML, declaration, attachment, approval and ERP implementation state move together, the product-change record gains authority. If they drift apart, the organization still has a PLM system, but it does not have a dependable operating record.

The Repeated Work That Decides Value

The repeated work in Agile PLM is not glamorous. A change analyst creates or reviews a change. Engineers add affected items. Component engineers update manufacturer data. Compliance managers request declarations or review supplier responses. Approvers examine redlines. Administrators adjust workflow criteria, privileges and lists. Integration teams monitor transfer queues and failed transactions. Users search for the latest record, check where-used data, attach drawings, review markup, respond to notifications and close out implementation status. This is where PLM economics are made or lost.

The best case is that repeated work becomes disciplined enough to reduce downstream ambiguity. A released ECO creates a new revision that downstream users can identify. A redlined BOM makes the change visible without requiring every reviewer to compare spreadsheets manually. An AML update keeps sourcing and manufacturing aligned when the design itself remains stable. A supplier declaration workflow turns compliance evidence into a controlled entity rather than an email attachment. An ERP integration posts released product design information in a form that manufacturing systems can consume. Each step removes one informal handoff.

But each step also creates supervision cost. Someone must decide which change type is correct. Someone must ensure the new lifecycle phase is set before release. Someone must maintain user privileges. Someone must keep supplier contacts accurate. Someone must decide whether a site-specific change belongs in an ECO, MCO or SCO. Someone must inspect failed imports, invalid values and transfer errors. Someone must keep the PLM configuration aligned with how the manufacturer actually operates. Agile PLM does not eliminate that work. It concentrates it in a governed system.

That concentration is useful when the alternative is chaos. In a company with complex products, multiple manufacturing sites, regulated materials and long support tails, the cost of uncontrolled change is often larger than the cost of PLM administration. In a simpler company, or in a business where product definitions live naturally inside a modern cloud suite or a tightly integrated CAD-PDM-ERP chain, the calculation can look different. The same controls that protect a medical device or high-tech electronics manufacturer may feel heavy for a company with fewer revisions, fewer suppliers or lower compliance exposure.

The important question is not whether Agile PLM can automate a change workflow. It can route changes, manage affected items, preserve history, connect to supplier and compliance entities and publish data outward. The important question is whether those workflows match the repeated decisions that the company has to make every week. If the system makes the right path easier than the workaround, users will feed it. If it makes the right path slower, unclear or poorly integrated, users will create side channels. The product-change record is only as good as the behavior around it.

This is where long-lived Agile PLM installations often reveal their condition. A healthy installation has controlled entity classes, current workflows, meaningful required fields, documented integration ownership, trained change analysts and a shared understanding of what release means. An unhealthy one has duplicate lists, obsolete fields, inconsistent item naming, approvals that happen outside the system, supplier contacts that no longer work, exports that are trusted more than the live record and customizations that no one wants to touch. Both may run the same software. They do not have the same operational value.

Integration Is Not A Footnote

For a product-change record, integration is not a back-office concern. It is the difference between a released engineering decision and a manufacturable instruction. Agile PLM can act as the design product-data system of record, while ERP usually controls purchasing, planning, inventory, costing and manufacturing execution. When those systems disagree, the shop floor and supply chain do not experience that disagreement as an architecture debate. They experience it as a wrong component, blocked order, surprise shortage, duplicate item, outdated drawing or unclear effectivity date.

Oracle's integration documentation makes the complexity visible. The release of a change order can generate Agile XML through Agile Content Service. The data may include change-order cover attributes, affected items, revised item data, BOM data and AML data. That data must then be transformed into the structure expected by Oracle E-Business Suite. The process can create new items, create an ECO, associate revised items with revisions and effectivity dates, create a new BOM and update transfer status in Agile PLM. This is exactly the kind of downstream continuity that an accepted product-change record needs.

Yet the same process shows why integration maintenance is a recurring burden. The destination system may not share Agile's exact change-type model. Site-specific AML data may not map cleanly to ERP structures. Duplicate item prevention may require lookup tables. The integration may need to decide whether an item already exists and whether a release is a first-time creation or an update. User exits may be needed for customer-specific transformations. Transfer queues can fail. Validation rules can reject data. The accepted record is therefore not guaranteed by the existence of a connector.

It depends on whether the connector's assumptions still match the business.

This is one reason spreadsheet workarounds are so dangerous in PLM environments. A spreadsheet can move faster than a controlled integration in the short term. It can also sever the link between the approved change and the implemented product. If a buyer updates a part attribute manually, if a planner creates an ERP item before PLM releases it, or if a site changes an approved manufacturer locally without feeding that information back into the lifecycle record, the company may not notice until a build fails or an audit asks for evidence.

Agile PLM's value lies in preventing those splits, but it cannot prevent them if the organization treats PLM as a paperwork layer instead of the record source.

The integration burden also shapes unit economics. A company does not pay only for the PLM license or support line. It pays for database administrators, application administrators, integration specialists, validation cycles, desktop compatibility, file-vault storage, supplier access, training, change-board time and migration planning. Those costs are acceptable when the system prevents expensive mistakes. They are hard to justify when the system merely archives decisions that have already happened elsewhere.

Compliance And Supplier Evidence Are Part Of The Record

Compliance is often discussed as a separate module, but in manufacturing it belongs inside the change conversation. A component change can alter substance exposure. A supplier change can alter declaration validity. A design change can affect documentation, testing, labeling, recycling or customer-specific requirements. Agile Product Governance and Compliance treats declarations, substances, specifications and part groups as structured entities that can connect buyer requests and supplier responses. That structure matters because compliance evidence decays when it lives only in inboxes.

The supplier side is especially important. Public Oracle documentation describes suppliers completing and signing off declaration requests, and compliance managers reviewing and approving declarations so that data can be published across the product record. That does not prove every customer uses the process well. It does define the supervision model. The buyer must identify parts and suppliers, create declarations, route them, validate completeness and correctness, release approved declarations and keep supporting documents attached. The supplier must respond with data that is accurate enough to rely on.

The PLM system can organize this exchange, but it cannot make a supplier know what it does not know.

This creates a realistic boundary for Agile PLM's claims. It can help gather, route, store and roll up compliance data. It can connect compliance evidence to parts, manufacturer parts and products. It can preserve declarations and supporting documentation. It cannot guarantee that a supplier's disclosure is complete, that a regulation has been interpreted correctly, that a substitute component has no hidden risk, or that every downstream team has waited for the latest approved evidence. The accepted product-change record is only as strong as the facts fed into it.

That boundary is not a weakness unique to Agile. It is the nature of PLM. Product lifecycle systems govern data about the product; they do not physically inspect every shipment, supplier factory or material batch. The reason to use such a system is that it gives the organization a controlled place to ask the right questions and preserve the answers. Without that place, compliance work tends to fragment into local spreadsheets, supplier portals, email threads and document repositories that do not share a product structure.

The highest-value compliance use case is therefore not "compliance management" as an abstract feature. It is a change record that refuses to treat compliance as after-the-fact paperwork. When an ECO or MCO changes the product structure or manufacturer context, the organization should know whether the compliance basis moved with it. If the answer is unclear, the change may be administratively approved but not operationally complete.

The Legacy Lifecycle Changes The Decision

Agile Software's current commercial setting is inseparable from its lifecycle. Oracle's public support policy lists Product Lifecycle Management 9.3.6 with Premier Support ending in December 2027, no Extended Support date and indefinite Sustaining Support. Oracle's Agile PLM roadmap also points to December 2027 for Agile PLM 9.3.6 Premier Support. That does not mean the software stops working the next day. It does mean the risk profile changes for customers who depend on it as a system of record.

Sustaining Support can preserve access to historical support resources, but it is not the same as an actively advancing product line. The question for customers is not whether an existing Agile PLM instance can continue to run. Many enterprise systems run for years after strategic investment shifts elsewhere. The question is whether it should remain the authoritative change-control environment as browsers, operating systems, databases, middleware, security expectations, supplier collaboration patterns and cloud integration needs continue to change.

Security makes the lifecycle issue more concrete. Public vulnerability records and scanner advisories have identified serious vulnerabilities affecting Agile PLM 9.3.6, including issues where network access could lead to compromise. A supported customer can patch, harden and monitor, but the direction of travel matters. A PLM system contains sensitive product design, supplier and compliance data. It may also sit near ERP and identity infrastructure.

A company that treats Agile PLM as a quiet engineering application rather than a business-critical system can underestimate the security work required to keep it exposed to users, suppliers and integrations safely.

Client and infrastructure requirements add another layer. Agile PLM 9.3.6 includes Web and Java clients, uses application servers, database servers, file managers, LDAP integration and optional components such as AutoVue and CAD connectors. The capacity-planning material describes different client performance characteristics, file-vault architecture, bandwidth behavior and platform dependencies. The 9.3.6 release-update documents show continuing changes for browser, security header, authentication and import behavior. These details are not mere technical trivia.

They are the maintenance surface that customers pay for when they keep a legacy PLM environment alive.

The lifecycle shift also changes the migration calculus. Moving from Agile PLM is not a simple data export if the current system contains years of item records, revisions, redlines, workflows, supplier declarations, attachments, custom attributes, integrations and validation evidence. Public market material from PLM vendors and integrators consistently treats Agile migration as a multi-phase effort involving requirements, configuration, integration, data migration, validation, training and change management. Those sources have commercial motives, so their claims need caution.

But the underlying point is credible: a system that has accumulated the accepted product-change record for years cannot be replaced like a document library.

For some manufacturers, the right decision will be to keep Agile PLM stable while planning a controlled transition. For others, the risk of remaining on a mature on-premises platform may push faster movement to Oracle Fusion Cloud PLM, PTC, Siemens, Aras, Arena or another modern PLM environment. The correct answer depends less on vendor slogans than on record fidelity. Can the successor preserve the product-change semantics that matter: revisions, effectivity, BOM redlines, manufacturer data, supplier evidence, compliance basis, approvals and downstream implementation history?

A cheaper or more modern system that loses that context is not a true replacement.

Where The Product Still Has Strength

Agile PLM's strongest argument is that it was built around the structured product record before that became fashionable language. The entity model recognizes items, changes, BOMs, manufacturer parts, approved manufacturer lists, supplier declarations, file attachments, workflows and history as governed data. That matters in industries where a product may remain in service for years, where suppliers change after release, where compliance evidence has to be retrievable and where engineering decisions must be traceable after launch.

The distinction between ECO, MCO and SCO is one example. It may look like process detail, but it reflects a real manufacturing problem. Not every change should create a new item revision. Some changes affect manufacturing data. Some are site-specific. Some require redlining a released BOM. Some affect lifecycle phase or effectivity. A system that models these differences can help a manufacturer avoid treating every product-data update as the same kind of event. That precision can reduce both over-control and under-control.

Another strength is the combination of internal and external collaboration. Supplier compliance data, approved manufacturer lists and declarations are part of the product record because many products are assembled from externally supplied facts. A PLM system that cannot bring supplier evidence into the controlled record leaves a gap between what engineering designed and what the supply chain can prove. Agile PG&C's supplier and buyer workflows show a mature understanding of this problem, even if actual performance depends on implementation quality.

A third strength is auditability. Workflow history, approval routing, attachments and controlled redlines make it possible to reconstruct why a change was accepted. That reconstruction may matter during quality investigation, customer escalation, regulatory review or internal post-launch analysis. The value of auditability is easy to undervalue until a product problem occurs. At that point, a clean record can save days of interviews and document hunting.

A fourth strength is installed familiarity. Many organizations have built processes, roles, reports, integrations and validation around Agile PLM. Familiarity is not innovation, but it has economic value. Users know where to find records. Administrators know local configurations. Integrations encode business rules. Validation packages may have been accepted by quality organizations. Replacing that familiarity requires not only software migration but behavioral migration. A modern interface does not automatically reproduce the institutional memory embedded in a mature PLM system.

These strengths should not be overstated. They are strongest when the implementation is clean and actively governed. They weaken when the instance is cluttered, integrations are fragile, support knowledge has retired or users distrust the workflow. Agile PLM's value is not inherent in the brand. It is earned by each customer's operating record.

Where The Failure Modes Begin

The most serious failure mode is BOM mismatch. If Agile PLM shows one product structure and ERP, CAD, PDM or the manufacturing site acts on another, the accepted product-change record has failed. The mismatch may come from manual re-entry, integration timing, duplicate items, poorly mapped sites, failed transfers or users editing downstream systems directly. The result is the same: the company cannot rely on one product truth.

The second failure mode is stale supplier data. Approved manufacturer lists and supplier declarations degrade over time. Parts become obsolete. Suppliers change formulations. Documentation expires. A change that alters supply context without refreshing the evidence can create a silent risk. Agile PLM can house the relevant records, but the organization must maintain the work of requesting, validating and releasing updated supplier information.

The third failure mode is weak approval discipline. A workflow that allows release without required lifecycle fields, approval context or signoff controls may be fast, but it reduces the meaning of release. Oracle's workflow documentation notes configuration practices around lifecycle phase requirements for ECOs and MCOs. That detail is important because the system may permit a weak configuration even when best practice argues against it. PLM governance is therefore partly a configuration discipline.

The fourth failure mode is migration error. Import/export and upgrade documentation show that data movement has constraints: formats, date handling, valid values, entity privileges, filters and database preparation all matter. A migration that preserves files but loses relationships, revisions, effectivity, supplier context or approval history can damage the very thing customers are trying to protect. The risk is not only that migration takes time. It is that a superficially complete migration can be semantically incomplete.

The fifth failure mode is integration drift. A connector that once worked can become unreliable as business rules, item classes, ERP configurations, sites, middleware or security settings change. Integration drift is especially dangerous because it may appear as a downstream exception rather than a PLM problem. A queue fails. A lookup misses. A data field no longer maps. A site-specific behavior is flattened. The release record looks correct, but implementation lags or distorts it.

The sixth failure mode is spreadsheet fallback. This is the quietest and most common substitute. Teams use spreadsheets because they are fast, visible and flexible. Spreadsheets are also easy to detach from approval history, supplier evidence and downstream implementation status. They are useful for analysis and preparation. They are dangerous as the final record of a controlled product change.

Unit Economics: When It Pays

Agile PLM pays when avoided errors are large, repeated and traceable to controlled product data. A manufacturer with thousands of parts, many suppliers, regulated materials, multiple sites and long product lifecycles can justify significant PLM overhead if the system reduces wrong builds, rework, compliance surprises and launch delays. In that environment, the cost of a bad change can dwarf the cost of maintaining a disciplined PLM process.

The economic benefit is rarely a simple headcount-reduction story. PLM often adds visible roles: change analysts, administrators, integration owners, compliance managers and supplier coordinators. The savings come from fewer hidden costs: less duplicate entry, fewer emergency reconciliations, fewer disputes about the latest revision, fewer supplier evidence scrambles, fewer manual data corrections and fewer downstream teams waiting for clarification. Those benefits are real, but they require measurement.

A company should track change-cycle time, rejection reasons, failed transfer rates, duplicate item incidents, supplier declaration aging, ECO aging, MCO aging, release-to-ERP latency and the rate of changes implemented outside the approved path.

The cost side is also broader than software. Licensing and support are only the beginning. Agile PLM installations require infrastructure, database care, middleware compatibility, file-vault management, identity integration, backup and recovery, patching, security hardening, user training, report maintenance, workflow governance and specialist consulting. If the customer is regulated, validation and documentation may add substantial cost. If the customer plans to migrate, the legacy system must often be kept stable while the target system is designed, tested and reconciled.

The commercial decision therefore turns on whether Agile PLM is still reducing the most expensive uncertainty. If the accepted record is trusted by engineering, manufacturing, sourcing, quality and compliance, the system can be worth its cost even near the end of Premier Support. If trust has moved elsewhere, Agile PLM becomes a high-cost archive and a migration liability. The dangerous middle state is when executives believe the system controls the product record while working teams rely on side processes to get products built.

Realistic Substitutes

The realistic substitutes are not one-for-one. ERP can manage items, planning, procurement and manufacturing changes, but ERP is usually weaker at engineering redlines, early design collaboration, CAD context and supplier compliance evidence tied to product structure. CAD and PDM systems can control design files and engineering structures, but they may not carry the full manufacturer, compliance, supplier and downstream implementation context. Quality systems can manage nonconformance and corrective action, but they are not necessarily product-definition systems.

Workflow tools can route approvals, but a routed approval without controlled product semantics is just a digital form.

Modern cloud PLM systems are the closest substitutes. Oracle Fusion Cloud PLM, PTC Windchill, Siemens Teamcenter, Aras Innovator, Arena and other platforms can address product records, change control and collaboration in different ways. Their advantage may be current investment, cloud delivery, improved interface, more active security posture and easier integration with modern enterprise stacks. Their challenge is migration fidelity. A manufacturer moving from Agile PLM must decide which data and workflow semantics are essential, which legacy customizations should die and which historical records must remain accessible.

The hardest part is not moving columns. It is preserving the meaning of accepted changes.

Third-party support and managed-service options are another substitute for immediate migration. They may help a customer keep Agile PLM stable longer, especially where migration risk is high. But they do not change the underlying strategic question. The more a company depends on Agile PLM as the living product-change authority, the more it must understand how support, patching, security, integration and skill availability will work after Premier Support ends.

Spreadsheets and custom internal tools are the least credible substitutes for complex manufacturing change control. They can be useful at the edge: data cleanup, analysis, pre-load review, supplier follow-up and reporting. They become risky when they replace the accepted record. A spreadsheet cannot easily preserve the full lifecycle of item revision, BOM redline, AML change, supplier declaration, approval, attachment, effectivity and ERP implementation state without becoming a fragile custom system in disguise.

The Practical Judgment

Agile Software's PLM lineage still has a defensible role where the product-change record is complex enough to justify disciplined control. The product is strongest when engineering change orders, manufacturer change orders, site changes, supplier declarations, compliance records, attachments, workflows and downstream integrations are configured around how the manufacturer actually releases products. It is weakest when those same entities become paperwork after the real decisions have moved to email, spreadsheets or ERP workarounds.

The accepted product-change record is the right test because it forces specificity. Did the change preserve item revision truth? Did it show exactly what happened to the BOM? Did it keep manufacturer and supplier context attached? Did it refresh compliance evidence where needed? Did approvers leave a usable trail? Did downstream systems receive the released data correctly? Did implementation status come back? Can the company reconstruct the decision a year later without interviewing half the project team?

If the answer is yes, Agile PLM may still return more value than it costs, even with lifecycle pressure. The company should still plan for the post-2027 support environment, security exposure and eventual migration path, but it should not casually replace a working product-record backbone. If the answer is no, the company should not confuse installed history with operating control. It should treat Agile PLM as a record needing repair, containment or migration, not as proof that product change is governed.

The final judgment is therefore conditional rather than nostalgic. Agile Software mattered because it helped manufacturers treat product data as controlled enterprise memory. Oracle Agile PLM can still matter when that memory remains accurate, approved and connected to the systems that build and support the product. But the value now rests on a narrow, measurable question: when a product change is accepted, does the record still carry the facts that make the change safe to manufacture, source, audit and maintain?