I seem to get this question a lot these days from end users, vendors, and even friends wanting to be in the tech market. “Why can’t I just build a content services platform (CSP) from scratch.” Let’s look at that same scenario but with a database.
Put yourself in the shoes of a startup CEO. You’re in a meeting with your new CTO who has just finished studying your companies visionary new solution. The CTO’s first recommendation is to build a database platform from scratch, “because there nothing out there.”
How would you respond?
You would not build a database from scratch. There are to many choices out there and building one would delay you several months. That being the case, why would you ever accept the idea of building a content services platform from scratch?
Managing files in volume is difficult
Building a simple file management system is easy. All it takes is a file system and a database. I’ve seen several applications that were developed by “Two Guys and a Computer” put into product only to fail once the platform hits full utilization. The challenge is not the functionality it’s the scale. Repositories of hundreds of millions to billions of objects are common.
While we no longer have theoretical limits to files in collections, buckets, or containers there are performance impacts. File size also impacts performance. Performance issues rarely appear in prototype environments or on day one. These performance impacts showing up nine months later in some cases crippling the systems.
But the repository is more than file storage. It’s about version control, editor integrations, workflow, records management, etc. All pieces that would need to be developed or included in the platform to meet the basic requirements of a content services platform.
Vendors – Build a content supply chain
In the vendor ecosystem today, content services applications (CSA) and content services platforms overlap. For example, let’s look at Contract Life Cycle Management where there are solutions from both CSA and CSP vendors. Both sides know what they do well, and they think they know what the others do too. It’s more likely that neither side knows what the other is doing. CSPs often have a better understanding of the overall content problem, while CSAs often have a better understanding of what exactly users want to do with content.
The benefits are simple math. A CSP talks to thousands of users about common problems with documents across organizations. This gives CSPs a great overview of the ecosystem, the forest. A CSA talks to thousands of users with specific business requirements. This give the CSA incredible detail into use cases, the trees. But if CSP talked to CSA, we’d be seeing the view of a million users.
End Users – Avoid another home-grown application
Every end user organization that been around for more than ten years have some sort of home-grown application that they are looking to replace with a commercial application. Your organization has better things to do with its IT budget then to spend it developing an application that already exists. Build versus buy rarely makes sense these days with the various options available.
Managing a content services infrastructure is a part time for a few individuals. Developing and maintaining your custom content services platform will require a small dedicated team. The problems that arise on your platform will often be new to your team, where they would probably have been addressed by vendors in the past.
Applications have options for platforms
The concepts of a CSA being built on a CSP is nothing new. It’s been going on for over twenty years. But for the first time there are many options. The choices include from CSP vendors, open source options, and file storage infrastructures. All with various pros and cons. Want to learn more? Don’t hesitate to reach out to your Account Executive to schedule an inquiry.
If you’re still leaning towards building your own CSP then ask yourself, “Now that you built it, do you want to maintain it for the next twenty years?”
Here are more posts from The CuSp