By Picturepark Communication Team • Feb 21, 2017
An interview with Picturepark Technology Program Manager, Stefan Seidl.
Among the design requirements for the Picturepark Content Platform was that it be built API-first, meaning the API would be modern, easy to understand and use, and offer complete access to the system and all the content therein.
For virtually all established digital asset management, content management and other such systems, APIs were an afterthought, tacked on after the system was originally designed with a “UI-first” approach. Access to a subset of system functions is common, but it is rare to find an API that enables developers to interact with legacy host systems however they want.
For Picturepark Content Platform engineers, the design goal for the API was easy: make it one they enjoyed using that they knew other developers would enjoy using too.
How did “API-first” start to become a game changer?
Before the phrase “as a service” became so widely used through the tech industry, we didn’t think so much in terms of one system being used solely as a service—everything was more self-contained in those days.
Today, it is common for systems to exist whose sole purpose is to provide data or processing to other systems. Mobile apps, for example, are often connected to backend systems that provide them with information they package and provide to users.
The most widely known category of service-based systems are those categorized as software-as-a-service, or SaaS, which describes running a complete software application that is hosted on a remote system. SaaS is easy for people to understand because they open a browser, connect to a URL and an application appears. This was the start of Picturepark 8, which has been available as a service since 1998.
From that, came platform-as-a-service, infrastructure-as-a-service, and so many other such concepts, I can’t even pretend to think of them all! But they all have one thing in common—some backend system that is accessed via API, and provides something to the systems calling it.
More recently, content-as-a-service came about. In this paradigm, there is a backend system that provides content to calling systems. Headless CMS is a popular example of this, but there are others. Stock quotes, weather, news feeds—these could all be considered content-as-a-service because the core information comes from a remote system.
The advantage to this is that the core content can be accessed any number of times from any number of places. Imagine, for example, all the places where you see the closing price of Apple or Google stock for the day. There is one master source for that data—the stock exchange. But that number gets published in thousands of locations, usually within seconds, because the data is available as a service, via API, to all those systems that need it.
How does this relate to content management?
Okay, so on a much smaller scale there is a need for individual companies to create and make available as a service their own content. Digital asset management was the start of this because companies realized that if they stored one copy of their logo in one location, there wouldn’t be variations of the logo everywhere, and they could track who downloaded it. If they did want to update it, they could do so in one place.
At one point, the only option to use a logo in the DAM was to download it and then upload it to the website or wherever else you needed. But then came the ability for the DAM to provide links that could display the logo on the fly. You could embed that link onto a website page and the most recent version of the logo would appear each time the page was loaded.
This was a content game-changer that worked great until the content game changed! Now, so much of the content we interact with isn’t file based, and much of it isn’t as simple as a logo.
Think about copyright notices or corporate policies or even office addresses. Where is the master file for your company’s copyright notice? Probably no one knows because there are so many copies of that content floating around. The footer of your website contains your copyright notice, but it is probably not a link to the actual master source of that information. So, if that notice ever changes, it must be manually updated everywhere it has been used.
If you Google “master data management,” you will see systems that were designed to be the master source of large data sets, like product catalogs, inventories, etc. But these systems are too much for the smaller chunks of content, like copyright notices, management bios and things like this.
The Picturepark Content Platform is a great solution for the management of these data snippets because it is easy to create and manage records for these contents, and they are not just accessible and editable from the API—the system with the API has been built so that other systems can become loosely or tightly coupled without mastering complex legacy technologies.
Picturepark can even pull master data from upstream systems and combine it with other data that is then sent downstream as a single API-digestible chunk. So, for example, your raw product data could come from a product information manager (PIM) or enterprise resource manager (ERP), then be combined with images and videos that are managed in Picturepark, and then sent via a single API call to a website directory or mobile app.
So, in a way, the benefit is not really just about the API, but in having a good API connected to a system that can abstract core content from the places in which that content is used, combine content from different sources, and then route that content wherever it is needed.
Can you provide a more basic explanation of this abstracting, combining and routing of content?
It can seem like a pretty complex concept, but there are simple real-world examples. Take, for example, a Word document that includes the text you type, images from Photoshop and tables from Excel. While you are working in the document, you are aware that each of these pieces of content have come from different sources. But once you “route” the document to the printer, it becomes one piece of content that includes everything. Those who read the document have no idea that the images were created on one application and the charts in another. They simply see a single document.
We wanted the Content Platform to be a hub through which content could be collected, combined and routed to websites, mobile apps or other systems that might further process it, In a way, this is not far in concept from what was hyped in cross-media publishing. The problem there was that systems didn’t become very user-unfriendly; they were complex and monolithic.
As the understanding of the power of “headless” access to content systems increases, people start realizing the benefits of disconnecting raw content from the output channels where it is consumed. Then they wonder what systems they can use for this. This is where the Content Platform becomes most valuable.
So the Content Platform is primarily a system that will be used by other systems rather than human users?
No, not at all! The Content Platform has a very nice user interface that makes working with all this content actually fun—even on a mobile phone! You can absolutely use the system as a stand-alone content system, like you might use Picturepark 8 today. It provides digital asset management features, like uploads, metadata editing, downloading and sharing—so there is no problem to use it just like that.
We speak of API-first and content-as-a-service because we believe this is what our customers will soon ask for. In fact, many have been asking for such functionality since a long while. So they will be able to use the Content Platform directly—without loosing DAM functionality that most headless CMS systems don’t offer—but they will also be able to connect it with more systems, services and apps, when the time comes and they are ready.
What developer resources will you make available for the Content Platform?
We will publish the Content Platform REST API, which includes several API endpoints to cover all areas. We’re building it by using the Swagger API framework. We will also make documentation, examples and other resources available through Github. We plan to Open Source not just the SDK but also some of our Connectors, so Github is a good solution for this. Pretty comprehensive SDK code examples will be available in Angular JS, C# and Java. We’re also working on integration frameworks that will enable developers to get up into selected parts of the Content Platform UI. More on this will be unveiled later this year.
We are also revamping our developer program and staffing up with API/SDK consultants who actually are developers so that we can be more responsive to developer needs, and more prepared to help them not just with coding but also the business side of things.
In general, the Content Platform will be an extremely developer friendly system, both in the technologies used and in the way the API enables them to write better code with much less effort. I personally am having much fun with this!
Other interviews in this series:
- Picturepark Director of Global Marketing, David Diamond, talks about whether products like the Picturepark Content Platform will be the death of digital asset management. Read that interview »
- Picturepark Product Manager, Olivia Schütt, explains how the Content Platform came to be. Read that interview »
- Picturepark Director of Engineering, Urs Brogle, speaks about the technology choices made for the Content Platform, and the challenges his team faced during development. Read that interview »