By Picturepark Communication Team • Mar 28, 2017
An interview with Picturepark Director of Engineering, Urs Brogle
If there’s one skill every software developer learns quickly, it’s being able to critique code written by others. There’s always a better way to do things, they reckon.
But what happens when the code you’re judging is your own?
Urs Brogle developed Picturepark. He has been with the company since the product was initially launched, and he has been instrumental in every update, architecture change and roadmap decision that has come since. It was Brogle who migrated Picturepark DAM from its ColdFusion origins to the .NET framework it is based on today.
It was also Brogle who was first to admit that he and his team had taken the 8-year old Picturepark DAM codebase as far as it should be taken.
You started over with the Picturepark Content Platform. Why?
No matter how well you build something, you always think about ways you can improve what you have done. This is the nature of software development. We build, we fix, we improve, we expand—this is, of course, the essence and value of software.
What we built with Picturepark DAM works well for what it was intended to be. But when we started to look at where content management was headed, I started to have doubts about being able to do everything we needed using the Picturepark DAM architecture. Could we do what we needed today? Almost certainly yes. What concerned me was not the 1.0 release of the Content Platform, but the 2.0, 5.0 and 10.0 releases. Could we do then what we needed? Almost certainly no.
Being able to start over, without concern for legacy issues, is exciting for developers; but we knew how much work it would be. Just changing the underlying architecture meant we would need to start over with sections of the program that really didn’t need to be changed at all. Changing passwords or managing rendering queues—these are maintenance aspects of the program that do what they need to do. Yet, these along with everything else, had to be recreated.
But the payoff for us was that we could bring in technologies and new fundamental concepts that would not only make for a more capable and reliable product today, but that have many years of evolution ahead of them.
Picturepark DAM is based almost entirely on Microsoft technologies. Is this still the case with the Content Platform?
The Content Platform is based largely on .NET, but the Microsoft logo was not a factor to us in choosing technologies. We evaluated all reasonable technology options and chose those we felt were best-of-class and, to be honest, fun to work with—not only for us, but for other developers too, which are an important target.
The “platform” aspect of what we were building was very important: whatever we chose needed be capable of dealing with an up-scaled, distributed architecture that was worthy of being called a platform.
What are some of the technological differences between Picturepark DAM and the Content Platform?
There are really too many to list them all. The Content Platform is an entirely new product. In general, we took the best high-availability and enterprise-worthiness aspects of Picturepark DAM and built upon them, taking advantage of the best of what’s available today.
Picturepark DAM search is based on SQL Search and RavenDB, but we’re using ElasticSearch for the Content Platform. The API is now based on JSON, and the complete architecture of the Content Platform has been designed “API first” for integration, with powerful integration frameworks and SDKs. Instead of Microsoft IIS as a web server, we’re using an integrated web server because of the new microservices architecture. The list goes on.
Most obvious to Picturepark DAM users will be way the Content Platform interface looks. We are limited in how we can design and style Picturepark DAM because of current Technologies. The Content Platform offers us many more possibilities, and will make updates much easier for us.
Angular is also the reason we can provide a good mobile experience on the Content Platform without having to create separate mobile OS-specific apps.
A number of the other improvements were about making the infrastructure more bulletproof. It’s not that we haven’t used SOA in some parts of Picturepark DAM. But the concepts of self-healing, graceful shutdown, and automatic recovery from hardware or network outages weren’t viable options to us when we designed Picturepark DAM. The Content Platform is much better at self-monitoring and self-management, also because Microservices are more consequently used.
Will any of these newer technologies be brought to Picturepark DAM?
This isn’t planned and it is not likely. Picturepark DAM does what it was intended to do, and there are many customers who rely on it to function as they are used to it functioning. In some cases, introducing Content Platform technologies into the DAM would be interesting, but it would be at the risk of stability of that system. Any time you make a significant change to such a complex system, you risk unintended results.
Now, with the majority of the Content Platform development behind you, do you already see things you would do differently?
In the core architecture, there is nothing substantial I would change. Over the years the Content Platform has been in development, there were choices we made early on that we have already changed because better options came available. This was possible because of that core architecture, so I’m very happy we have that.
We have not yet explored even a fraction of the potential the Content Platform offers. Really, for the first time in the history of Picturepark, we are built upon a technology stack that goes beyond any limitations we can see now.
So, I’m not thinking so much now about what we can change about what we have built, but about what we will build next using what we have built.
Next month, we’ll hear from Picturepark Director of Global Marketing David Diamond about whether the Picturepark Content Platform marks the “death of DAM” or the birth of something entirely new.
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 Technology Program Manager, Stefan Seidl, discusses changes to the Picturepark API, and what new opportunities are available through the “API-first” approach. Read that interview now »