{"id":981,"date":"2021-04-07T15:02:55","date_gmt":"2021-04-07T13:02:55","guid":{"rendered":"https:\/\/dam-evangelist.blog\/?p=981"},"modified":"2022-10-14T17:10:21","modified_gmt":"2022-10-14T15:10:21","slug":"die-leber-waechst-mit-ihren-aufgaben-und-ihr-dam-system","status":"publish","type":"post","link":"https:\/\/dam-evangelist.blog\/en\/2021\/04\/07\/die-leber-waechst-mit-ihren-aufgaben-und-ihr-dam-system\/","title":{"rendered":"The liver grows with its tasks – and your DAM system?"},"content":{"rendered":"

\"The<\/a>
\nDie Leber w\u00e4chst mit ihren Aufgaben (The liver grows with its tasks) is a bestseller by cabaret artist and physician Dr. Eckhard von Hirschhausen (Die Leber w\u00e4chst mit ihren Aufgaben – at Amazon).
\nEmblematic of the title, Hirschhausen tells anecdotes from medical life in a humorous way.
\nNow of course, as someone like me who appreciates a good glass of red wine, one should not misinterpret this title, however, it actually animated me to write this new blogpost.<\/p>\n

Quite apart from the humorous side, wouldn’t it be a great thing if things grew with their tasks?<\/p>\n

Certainly this exists in many areas of life, but what about my favorite topic the DAM systems?
\nMany companies are still running and acquiring legacy DAM systems, most without even realizing it.
\nThe market for DAM systems has grown. Some systems have been on the market for 20 years without ever having implemented significant updates to their software source code and application design.
\nVery often, there are simply cosmetic improvements, mainly concerning the user interface.
\nCool and functional user interfaces are very important for a coherent product, but they should not serve as the only selling point for a system.
\nAlready Steve Jobs said:
\n“Design is not how it looks. Design is how it works.”
\nAnd as so often, Steve Jobs is absolutely right here. So only if the right architecture is also installed “under the hood” will your DAM work reasonably.<\/p>\n

Most of the legacy DAM systems definitely do NOT grow with their tasks, but quite the opposite, their performance decreases drastically with increasing tasks!<\/p>\n

The ever-growing omnichannel marketing process, requires DAM systems to be highly scalable.
\nIt is fatal to opt for a system that already has a limit set by its architecture.<\/p>\n

How can you scale up the omnichannel process if the heart of the chain is limited?<\/p>\n

How can you handle a dramatic increase in data volume if a system can’t scale up and down dynamically?<\/p>\n

How to handle user search requests and API calls from third-party systems if databases and search indexes cannot be expanded?<\/p>\n

Basically, there are many different ways to scale systems.
\nIn the past, it was mainly hardware that was scaled up, only to find out that this was unfortunately not a solution to the actual problem.<\/p>\n

Nowadays, hardware undersizing is only a very rare reason why a DAM system is no longer doing its job in terms of performance.<\/p>\n

The much more common reason lies in the design of the software solution itself.
\nThe data model, the structuring of the individual processes, the lack of parallelization of processes, and the lack of queuing systems, etc. are the most common reasons.<\/p>\n

So how do you recognize well-designed DAM systems?<\/p>\n

This is a challenge for which you need a little know-how!<\/p>\n

A first important point is to have the architecture presented and explained.<\/p>\n

Of course, you need to have at least a basic knowledge of software and application design. A DAM system can be decomposed in principle into different “services” for example:
\n– Storage to store the binary media data
\n– Database for storing references and meta information
\n– Rendering engine for creating previews and derivatives
\n– Search index for searching assets
\netc.
\nEach of these components must be well designed in itself, as well as the interaction of all components. Do not be afraid to seek external help if you lack the knowledge to evaluate these architectures yourself. This is essential for selecting the right DAM system!<\/p>\n

A second point can be the request for benchmarks.<\/p>\n

Here you will probably encounter great surprise, as most DAM vendors do not create benchmarks for their software. Benchmarks are an important indicator of how a system behaves under load. Here several simultaneous user accesses and API accesses depending on the amount of data etc. can be combined. This gives a very good impression of what a system is really capable of.
\nIf the manufacturer does not have their own benchmarks, these can be simulated, created and evaluated via calls to the API (which hopefully every DAM has!!!). Again, they will probably get external support for this, but it will definitely be worth it for them!<\/p>\n

And last but not least:<\/p>\n

Ask the manufacturer of the DAM system a “hole in the belly” and get answers in writing.<\/p>\n

Questions could be, for example:
\n– Can I add a second database at any time in the standard if one instance is no longer sufficient?
\n– Can I easily scale the search index and at what point (number of records) does it make sense to start scaling?
\netc.<\/p>\n

Assessing whether a DAM system has a solid, coherent and, above all, scalable architecture is certainly not easy for a layperson. Nevertheless, it is an assessment that absolutely must be made in order to avoid any nasty surprises.
\nIf you have any questions or suggestions, I look forward to hearing from you!<\/p>\n

 <\/p>\n

\n

\u2190 Back<\/a><\/p>

Thank you for your response. \u2728<\/h4>\n\n