What is our primary use case?
We use FileNet with our Cognos. We used to store all of our report history within Cognos, inside the content store. We've removed it from the content store and put it inside the FileNet system. Our users can still access their reports, but we don't have to store it in our content store.
How has it helped my organization?
Our main benefit is keeping our content store small, where our content store was about 5.5GB. Best practices from IBM is about 3GB, so we were way over that. By moving all the report history out of the content store, we're now down to about 1.5 to to 2GB.
What is most valuable?
Keeping our content store small. That helps our DBAs when they have to do the backups of our audit system, or of the content store. It's in SQL Server, and to back up SQL Server of something that size takes a lot of time and a lot of effort. But now that we've shrunk that down, it's a little bit more manageable to handle backups. I know if we do ever have to restore our content store - which we hope we never do - we're able to do it in a more timely fashion because it's smaller in size.
What needs improvement?
It does what we need for it to do. As long as it can continue to handle the volume that we're throwing at it, I don't think that it's going to be a problem.
What do I think about the stability of the solution?
We've been using it now for about four years. When we first went to it, we were having some issues, communication across the network issues, but we have had very few issues with it.
What do I think about the scalability of the solution?
We add stuff to it all the time, so it's scaling vertically all the time, and we haven't had any issues with it. We started out around 3GB, and we're up to about 5GB, and we expect to be somewhere at around the 10 to 12GB mark by 2020, just because that's the way our business is growing.
How are customer service and technical support?
One of our account reps was very instrumental in getting us set up, but we really haven't had, other than network latency issues in the very beginning, a lot of issues where we needed to go to technical support for it.
Which solution did I use previously and why did I switch?
We were using the out-of-the-box content store of Cognos, and we were just busting at the seams, so we had to come up with a solution. One of our account reps actually came up with the solution. We looked at a couple other things, but this was a solution we decided to go with.
The important criterion for us when selecting a vendor is mostly that it's going to handle volume. Our particular company is a distribution system, and so we have tons and tons of data, so we need to be able to handle volume. What we typically run into is, people give us a proof of concept, and it will handle it with a small use case. But when you try and explode that use case into something that we need, at the volume we're working at, many of those solutions just fall flat at that point. This particular solution, that didn't happen.
How was the initial setup?
It was pretty straightforward. Like I said, the biggest issues we had were on our company side, the network latency of moving that much data across our network at one time. Once we opened up a dedicated pipe for that data movement, we haven't seen any issues like that.
What other advice do I have?
I'd give it an eight out of 10. Eight's not high, not low, necessarily, but it does everything we need. I'm not going to give anything a 10, but I'm definitely not gonna give it a one.
I would say you need to take a look at the size of your content. If you're going to use it to replace the content store of Cognos, you need to look at the size and make sure you're within best practices. Cognos is a product that's wishy-washy at times, and most of the issues that we've ever had with Cognos were because our content store was too big. Now that we've shrunk the content store, our Cognos is actually better. If you are looking at that, this would be a solution I would suggest to you, just to keep your content store small.