Immutable Storage Paths for Attachments in Workitems

As the ELM database is not intented to store big workitem attachments, an option is to use an external file storage. The path to the storage can be only defined once. It is also not possible to switch back to the database as a storage location for attachments.
 

At the core of this issue is the teamserver.properties configuration file, where the attachment storage location is defined (e.g., com.ibm.team.jfs.app.storage.area.file.root). Upon initial server startup, this path is written into the Jazz Foundation Service (JFS) database and becomes effectively "baked in." Any subsequent changes to this property in the configuration file are ignored by the running application, as it continues to reference the path stored in the database.

This architectural choice creates a hard-coded dependency between the application logic and the physical storage infrastructure. For any enterprise environment that is not static—which is to say, all of them—this immutability is not just an inconvenience; it is a critical flaw that undermines the platform's viability in dynamic IT landscapes.

The technical limitations described above have direct and severe business consequences:

• Increased Total Cost of Ownership (TCO): Higher costs for infrastructure (expensive file servers vs. cheaper object storage), manual administration, complex migrations, and extended downtime all contribute to a higher TCO.
• Reduced Business Agility: The inability to quickly clone environments, failover for DR, or migrate to the cloud slows down the entire organization. It makes the IT department a bottleneck rather than an enabler of business strategy.
• Hindered Scalability: The reliance on traditional file shares creates a scalability ceiling. As data volumes grow into the hundreds of terabytes or petabytes, the file system model becomes technically and financially unsustainable.
• Elevated Compliance and Security Risk: Complex, manual procedures for DR and environment cloning increase the likelihood of human error, leading to data loss, security breaches, or failure to meet regulatory compliance mandates (e.g., SOX, GxP, ISO 26262).

The immutable attachment file share path in IBM EWM is a significant architectural flaw that is out of step with the demands of modern, large-scale enterprise IT. It creates unnecessary friction, cost, and risk, hindering key strategic initiatives like cloud adoption, DevOps acceleration, and business continuity planning.

We strongly recommend that IBM Product Management and Development prioritize the implementation of a flexible and dynamic attachment storage architecture i.e. the path to the attachment storage is changeable.

A solution, preferably a full storage abstraction layer with support for object storage, would not be a mere feature enhancement; it would be a fundamental modernization of the platform. Addressing this deficiency is critical to ensuring EWM's continued relevance and viability as a best-in-class enterprise solution, safeguarding customer investment, and enabling them to build resilient, scalable, and agile engineering ecosystems.