Recently we had a great day at our HQ with Nasry Angel from Forrester discussing our Roadmap and Visions. During the discussion, we talked about different approaches to architecting software.
If you simplify it, you can categorize these approaches into two main categories.
Here it is all about The Expert, and an assumption that this solution will handle everything from here to eternity. Or perhaps with this expert aura it simply becomes too many features within one solution, and too few that dare to challenge the solution. In the 90s this was a popular way of approaching software architecture. Trying to build and capture THE Enterprise Model that would solve everything and with that false expert know-it-all notion this could be done. Meanwhile, the business had to wait while the experts sat down and did their analysis, and after that it was done. The only thing that now remained was for anybody or somebody to implement their flawless design and voilà the one model was built.
To quote Jimmy Nilsson on why this did not work on the 90s and why it will not work in the future either:
This approach often leads to a big on-premise monolithic design. Over time this will not scale with new creative ways of solving real business challenges, but more be a war for preserving a state and design that was built and invented during the analysis and the creation of THE Enterprise Model.
Here it is all about knowing that we do not know what the future holds, hence we need to approach our domain with that notion. Understanding and accepting that everything we add will create complexity, so being very aware of what type of business challenge we are solving is paramount. Because we know that the domain and business challenges will change many times during the lifetime of our design. If other or tangent business domain opportunities arise, look for other services or collaborations to solve it. This approach of moving forward in small steps and failing fast, but with tiny failures that quickly will lead to a path towards an efficient design. In hindsight, this path will look crisp and clear, but without these small failures it would have been impossible to find it.
This approach often leads to a SaaS-based design with Microservices as base architecture, which often gives more flexibility and more purpose-built features . This often fits better within an organization. Because of the natural state of a IT-landscape where a lot of different systems and services often needs to coexist. To assume that ONE system would solve this challenge in the most efficient way is not very realistic. If you on the other hand are working with modern service-based solutions, this will put you in a much greater position to be efficient in maximizing the effect of your investments.
A couple of weeks ago me and our CEO, Niclas Mollin returned from San Francisco after attending the great event SaaStr 2017. The reinforced insight we left with was that all inRiver customers deserve a modern approach to delivering software. We have, for a long time, believed in a Cloud Service Approach, but with that transition we had to go through a lot of changes. To get where we are now, we have “killed a lot of darlings” on the way. With this I mean things that were thought of as absolute musts in our solution, and could not be changed. As always with these situations, time and commitment will help you in finding an alternate route. In this change process, The Microservice architecture is something that has helped us in our ambition to ― together with our community ― create an easy-to-use and fast-to-scale SaaS approach. The feedback we have received is very positive, the agility we can provide and the speed of change our design offers is very appreciated by our customers.
Think big – Start small - Scale fast
Jimmy Ekbäck, Executive Vice President Products & Services, inRiver
As customer interactions are rapidly moving to the digital channels, organizations need to address the inefficiencies in their content production processes. Shooting from the hip just won't cut it anymore, not even in the creative department. You have to have a disciplined approach to get the right product content produced and distributed to the right channels at the right time. Creating and distributing more content faster cannot be done efficiently using a brute-force approach or by simply adding more people. Instead, it needs to be done by working smarter rather than harder—and finding system support to help you achieve efficiency in your content production processes.
Does your organization require a solution for PIM, DAM, or both?
In their search for a solution that can help them to achieve the required efficiency, many organizations ask themselves if they need a solution to manage their product information (PIM) or one that manages their digital assets (DAM). There are some questions that we need to answer before we can decide that:
Products typically need to be described and augmented using numerous different types of information, such as specifications, USPs, descriptions, documents, up-sells, cross-sells, and much more. This information must be of high quality, be granular, and be very structured. Depending on the industry and product type it also needs to be a part of an ecosystem—for example, as a part of a bundle, solution, repair kit, look, or room. To have a complete and compelling product story it also requires an ever-increasing number of digital assets, from 360 spins and how-to-videos to regular static photos.
We can conclude that we must be able to manage product data and product-related digital assets at the same time. Thus, we cannot choose between PIM and DAM as we need both to support the creation and distribution of a complete and compelling product story. Simply put, a DAM cannot manage the product data and the product ecosystem, so as long as you're not selling images, going with just a DAM to manage your product information will not be sufficient. Do you need two separate solutions? To know that, we need to define more granular requirements.
If you do not manage large volumes of digital assets that are nonproduct-related and choose a PIM solution with strong built-in DAM capabilities, you most likely don't need a separate DAM. The built-in one will be sufficient and already tightly integrated. However, if you do manage large volumes of nonproduct-related digital assets, you should consider adding an enterprise DAM solution and integrate that with your PIM system. The integration with a PIM is necessary as it will drastically reduce the metadata maintenance and automate the distribution of the assets to the channels.
How to manage the selection and review of assets?
WIP, short for Work In Progress, usually represents the first step of the creative workflow, right after or during the photo shoot, but before final delivery to a PIM or a DAM. Sometimes I meet with organizations that believe they need a DAM, when in reality, they are need of a Work In Progress system. A tool that manages the WIP process can be used to streamline review and approval for digital assets and make the selection process easier and faster, so it makes sense that some DAM solutions have this built-in as a feature. Whether you choose to integrate a DAM or use the built-in one in your PIM, adding WIP process support can provide additional efficiency gains.
Whatever you do, don't hamper your sales by shooting from the hip in the content creation process.
Johan Boström, Co-founder and Evangelist, inRiver