von Picturepark Communication Team • März 28, 2017
Wenn es eine Kompetenz gibt, die sich Softwareentwickler schnell aneignen, dann ist es die Fähigkeit, von Anderen geschriebenen Code zu kritisieren. Sie gehen immer davon aus, dass es einen besseren Weg gibt, die Dinge zu tun.
Aber was passiert, wenn sie ihren eigenen Code beurteilen??
Urs Brogle hat Picturepark entwickelt. Er ist für das Unternehmen tätig, seit das Produkt auf den Markt wurde, und er war seitdem maßgeblich beteiligt an jedem Update, jeder Änderung der Architektur und jeder Entscheidung im Rahmen der weiteren Entwicklung des Produkts. Es war Brogle, der Picturepark DAM von seinen ColdFusion-Wurzeln auf das .NET-Framework migrierte, auf dem es heute basiert.
Es war auch Brogle, der als erster feststellte, dass er und sein Team den acht Jahre alten Programmcode von Picturepark so weit entwickelt hatten, wie er nur entwickelt werden konnte.
Sie haben mit der Picturepark Content Plattform ganz neu begonnen. Warum?
Egal, wie gut man etwas baut, man denkt immer darüber nach, wie es verbessert werden könnte. Das ist die Natur von Softwareentwicklern. Wir programmieren, wir reparieren und verbessern, wir erweitern – das ist einfach das Wesen und der Wert von Software.
Was wir mit Picturepark DAM geschaffen haben, hat gut funktioniert für den Zweck, für den es gedacht war. Als wir aber erahnten, wohin sich Content Management entwickeln würde, begann ich zu zweifeln, ob die Architektur von Picturepark DAM geeignet war, die nötigen Funktionen zu realisieren. Hätten wir das tun können, was wir heute benötigen? Ja, mit ziemlicher Sicherheit. Ich war nicht besorgt wegen der Version 1.0 der Content Plattform, sehr wohl aber wegen den Versionen 2.0, 5.0 und 10.0. Wären wir in der Lage, die dann erforderlichen Funktionen zu realisieren? Wohl kaum.
Die Möglichkeit, noch einmal ganz von vorn zu beginnen, ganz ohne Sorgen um die Kompatibilität mit früheren Versionen – das ist sehr spannend für Entwickler. Aber wir wussten, wie viel Arbeit es sein würde. Die Änderung der zugrunde liegenden Architektur bedeutete, dass wir auch die Teile des Programms ändern mussten, die sonst keiner Überarbeitung bedürfen. Die Vergabe von Passwörtern und die Verwaltung von Rendering-Warteschlangen – das sind Wartungsaspekte des Programms, die einfach tun sollen, was sie tun müssen. Doch dieses Mal mussten wir auch sie von Grund auf neu erstellen.
Der Vorteil war, dass wir Technologien und neue fundamentale Konzepte einbringen konnten, die nicht nur heute für ein leistungsfähigeres und zuverlässigeres Produkt sorgen würden, sondern die auch eine viele Jahre andauernde Evolution ermöglichen würden.
Picturepark DAM basiert fast ausschließlich auf Microsoft-Technologien. Gilt das auch für die Content Plattform?
Die Content Plattform basiert weitgehend auf .NET. Das Microsoft-Logo war aber kein Aspekt bei unserer Wahl der Technologien. Wir haben alle naheliegenden Technologieoptionen geprüft und dann ausgewählt, was wir als am besten geeignet einstuften. Und was, um ehrlich zu sein, auch Spaß bei der Arbeit macht – nicht nur uns, sondern auch anderen Entwicklern, die eine wichtige Zielgruppe sind.
Der Plattform-Aspekt war sehr wichtig für das, was wir entwickelten. Was immer wir wählten, es musste in der Lage sein, mit einer gehobenen, verteilten Architektur umzugehen, die würdig wäre, als Plattform bezeichnet zu werden.
Was sind einige der technologischen Unterschiede zwischen Picturepark DAM und der Content Plattform?
Es sind zu viele, um sie hier alle aufzulisten. Die Content Plattform ist ein völlig neues Produkt. Generell ist zu sagen, dass wir die besten Aspekte in Sachen Hochverfügbarkeit und Eignung für Großunternehmen aus Picturepark DAM übernommen und darauf aufgesetzt haben – unter Nutzung des Besten von allem, was heute verfügbar ist.
Die Suche in Picturepark basiert auf SQL Search und RavenDB, für die Content Plattform nutzen wir aber ElasticSearch. Das API basiert nun auf JSON, und die komplette Architektur der Content Plattform wurde mittels des „API first“-Ansatzes für Integrationen vorbereitet – mit leistungsfähigen Integrations-Frameworks und SDKs. Anstatt Microsoft IIS als Webserver nutzen wir nun wegen der neuen Microservices-Architektur einen integrierten Webserver. Die Liste könnte ich noch lange fortsetzen.
Für Picturepark DAM-Nutzer wird eine der offensichtlichsten Neuerungen das Aussehen der Oberfläche der Content Plattform sein. Picturepark DAM basiert auf Technologien, welche uns in Bezug auf das Design limitieren. Die Content Plattform ändert das und eröffnet uns weit mehr Möglichkeiten, was auch Updates deutlich vereinfachen wird.
Angular ist auch der Grund, warum die Content Plattform auch auf Mobilgeräten eine gute Benutzererfahrung bieten wird, ohne dass wir für jedes Betriebssystem mobile Apps erstellen müssen.
Mit einer Reihe anderer Verbesserungen wurde die Infrastruktur sicherer gemacht. Es ist ja nicht so, dass wir SOA nicht schon in einigen Teilen von Picturepark genutzt hätten. Aber die Konzepte von Selbstheilung, sanfter Abschaltung sowie automatischer Wiederherstellung nach Hardware- oder Netzwerkausfällen waren im Rahmen der Entwicklung von Picturepark DAM keine praktikablen Möglichkeiten für uns. Die Content Plattform ist in Bezug auf Selbstüberwachung und -management viel besser – auch weil Microservices viel konsequenter genutzt werden.
Wird eine dieser neueren Technologien auf Picturepark DAM gebracht werden?
Das ist derzeit nicht geplant und auch nicht wahrscheinlich. Picturepark DAM macht, wofür es gedacht ist, und viele Kunden verlassen sich darauf, dass es so funktioniert, wie es soll. In einigen Fällen wäre die Einführung von Technologien der Content Plattform in das DAM interessant, würde aber die Stabilität dieses Systems gefährden. Mit jeder wesentlichen Änderung eines solch komplexen Systems riskieren Sie unbeabsichtigte Ergebnisse.
Die Entwicklung der Content Plattform wird bald abgeschlossen sein – siehst Du schon Dinge, die Du anders machen würdest?
Bei der Kernarchitektur würde ich nichts Wesentliches ändern. Im Laufe der Jahre der Entwicklung der Content Plattform haben wir frühe Entscheidungen getroffen, die wir später wieder überworfen haben, weil bessere Möglichkeiten verfügbar wurden. Das war eben wegen dieser Kernarchitektur möglich, und ich bin sehr froh, dass wir diese haben.
Wir haben noch nicht einmal einen Bruchteil des Potenzials erschlossen, das die Content Plattform bietet. Wirklich, zum ersten Mal in der Geschichte von Picturepark setzen wir auf einer Technologie auf, die immer wieder alle Limits sprengt, die wir sehen.
Also, ich denke nicht so viel darüber nach, was wir an dem ändern könnten, was wir entwickelt haben. Sondern eher darüber, was wir auf dieser Basis als nächstes machen können.
Andere Interviews in dieser Serie:
- David Diamond, Direktor von Global Marketing bei Picturepark, spricht darüber, ob Produkte wie die Picturepark Content Platform der Tod des Digital Asset Management sein werden. Lesen Sie dieses Interview »
- Stefan Seidl, Technology Program Manager bei Picturepark, erläutert Änderungen des Picturepark APIs und welche neuen Möglichkeiten der „API-first“-Ansatz bietet. Lesen Sie dieses Interview »
- Olivia Schütt, Product Manager bei Picturepark, erläutert, wie die Content Plattform entstanden ist. Lesen Sie dieses Interview »