CHAPTER 9
You’re Not Just Buying a Tool: Strategic Considerations
Channel Professional Services: Support and Community
The DAM market consists of global, regional, and local vendors (see Figure 9.1). Strategic considerations can vary considerably among vendors depending on their provenance, size, and other factors. The fit of a particular vendor to your enterprise needs, culture, and orientation is as critical to your overall success as the suitability of its DAM product. In the following sections, we describe what other factors to consider when looking at any product.
FIGURE 9.1
The vendor ecosystem.
Vendor Professional Services
In the typical DAM project, customers spend more on services than on software, sometimes two to five times more. To meet customers’ consulting needs, most vendors maintain their own professional services organization (PSO). Most vendors also have a “partner channel” around their products, with which they may even compete. These integrators, partners, and resellers can help implement the package. The ability of partner channels varies dramatically from vendor to vendor and can change over time
When possible, you should find experienced services geographically close to you to avoid paying for consultants’ hefty travel costs. Investigate a potential partner’s “soft” skills, such as information architecture and a good sensitivity to organizational issues, in addition to product knowledge. Doubly investigate a partner’s product knowledge because some partnerships are in name only and integrator skill and expertise can fluctuate wildly from product to product—even from the same vendor. Perform as careful diligence of all consultancies as you did of the product itself.
Don’t overlook the possibility of bringing in an independent developer or consultant to provide knowledge and assistance. Products with longevity in the market typically boast more—and more experienced—consultants. Many of these consultants are alumni of vendor PSOs, which tend to have high staff turnover. On the other hand, the longer a tool has been out there, the higher the demand for these independent consultants, so the more they cost. Always require documentation for independent work done on your system.
Like support, many factors influence the quality of the implementation services you receive. Vendors often have “A” teams of their top-notch implementation consultants—and then everyone else. “A” teams tend to work only on the biggest or most prominent client projects. “Everybody else” within a vendor PSO can include contractors that the vendor may or may not have trained on its tool.
The vendor’s own PSO knows the product best but may be stuck in older ways of doing things. The PSO may not be up to speed on—or even favor—the product’s latest capabilities and modules. It may also bring a set of informal, subsidiary modules to your implementation that the company does not officially support as part of your separate software license agreement. Be sure to understand any potential exposures here.
For open source platforms, the availability and quality of services matters even more, because many of them tend to be complex to install and configure. As in the commercial world, tension builds between the project “founders” and other firms trying to make money providing services and support. You may end up working with a mixed team of core project founders and local developers, much as you might with a commercial vendor. This places a premium on your ability to manage multisupplier projects.
SaaS vendors tend to provide an array of services. That’s how they make money, and the major SaaS/cloud players are generally good at it. The downside is that they typically don’t have strong partner channels because they tend to do most of the services work themselves. Therefore, you may need to get comfortable working with an off-site consulting team when you sign on with a SaaS provider.
In almost all cases, selecting a “hot” vendor or product has a big downside. Consultants who know the tool will be in high demand. As a result, they will likely be scarce, expensive, and itinerant. Without adequate expertise, you may lose the added advantage that the innovative technology was supposed to bring. Before you select a tool, make sure you know where, when, and how you are going to line up the necessary expertise to implement it properly.
Integration and Partnerships
How effectively does the vendor’s technology mesh with that from other suppliers? First, let’s note that not all integrations include a formal partnership. Second, a partnership doesn’t guarantee effective integration between two vendors’ products because most vendors enter into partnerships for business and sales purposes, not to accomplish a firm technical objective.
Caveats aside, some vendors seem innately more open to integration with complementary or adjacent technologies. They don’t necessarily have more open APIs; rather, they make a point of being more conducive to integration. Other vendors have a culture of trying to build everything themselves.
The depth of a specific integration to another tool that is very important to your enterprise may matter more than the breadth of a vendor’s partnerships. If, for example, your enterprise uses SAP for billing and accounting, the ability to integrate seamlessly to that environment to exchange metadata may become paramount. Some DAM vendors pay close attention to their relationships with Microsoft to the exclusion of nearly all other third-party suppliers, giving them tight integrations with the latest server and client technology from Redmond. The only way to know if a partnership or integration is real is to talk to customers who have put the two technologies together in a production environment. Ask detailed questions about the level of effort and methodologies required. Don’t be surprised if they need substantial professional services.
Most DAM vendors have put their energies around Web services in general—and SOAP in particular—regardless of the performance and security shortcomings that still exist with that model. A more REST-oriented approach borders on nonexistent. Don’t expect to be able to easily remove discrete services from or insert them into your DAM Web services.
Channel Professional Services: Support and Community
All technology buyers want to know, “How well does the vendor support the product?” All vendors rave about their product support. Nearly all customers complain about vendor support. What’s going on here?
Factors Affecting Support
Many factors determine whether a vendor’s support will meet your needs. One key consideration is that vendors often offer different support mechanisms in different countries or locales. These differences may include different hours of support or varying expectations about how much first- and second-line support will be handled by a local partner. In general, the larger the vendor, the more variable you’ll find first-line support. Some large vendors outsource it. That’s not necessarily a bad thing, but the person on the other line may never have actually performed an implementation of the product. Many small companies let customers reach “real” engineers in times of acute trouble. Smaller vendors, however, often have difficulty providing the 24/7 support that enterprise customers have come to expect. In almost all cases, you can elect to spend more for higher levels of support.
It is a fact of the software business that a vendor’s larger and more prominent customers receive better support. Agreeing to take reference calls and speaking at user conferences also doesn’t hurt. Of course, you don’t necessarily want to be a vendor’s biggest customer if it doesn’t have the capacity to support you adequately.
Rest assured that the day will come when you will need to escalate a problem up through or beyond your vendor’s support department. If you are a small fish in that vendor’s pond, your chances of getting what you want drop substantially compared to your larger brethren. Customers who have contracted with their vendor’s professional services organization sometimes later turn informally to the specialists who worked with them when a problem crops up, but don’t count on it.
In general, cloud-centric software-as-a-service vendors provide better support because they’re on the hook for monthly fees from you. They are also more likely to support your designated lead users as well as your developers. Traditional vendors typically ask you to support your contributors while they support the software. In addition, SaaS vendors are providing a service, so the line between professional consulting and support becomes a bit blurrier. To that end, be sure that your support contract with a SaaS provider clearly defines what constitutes tech support and what constitutes site enhancements.
Regardless of whether you end up with SaaS or you acquire the software, it’s a best practice to funnel all support calls to a central log within your company—even if multiple people are calling support. This helps you understand if there are systemic software defects—or perhaps see the need for better training. It will also greatly help with your vendor relationships if you have good insight into the patterns of your calls, especially when something needs to be escalated.
Community Strength
A thriving DAM community has formed across all asset management users. Thriving user communities provide informal support in the form of peer interactions and user group meetings. Alas, your support needs will have to be met by the vendor and its partner ecosystem. Within this environment, does the vendor provide you with access to other users of its product? A small but growing factor is the availability of authentic community support, including vendor developers, integrators, and customers. Few commercial vendors have attempted to match the level of support ecosystem that you can find in an open source software community. Don’t underestimate the value of this kind of informal support. Vendor user-group meetings are also extremely helpful, allowing direct interactions with your peers. These group meetings also give larger or more geographically focused vendors additional leverage to compensate for their own somewhat impersonal support channels. Developer extranets are rare but invaluable. We encourage you to take advantage of meet-ups if you live in London, New York City, Chicago, Los Angeles, or Washington, DC. You also may benefit from the Henry Stewart DAM conferences and the DAM Foundation.
Documentation
You should not rely solely on a vendor’s documentation to teach, explain, or even adequately document how a system works. Instead, invest in formal training for both developers and contributors; also, cultivate relationships with the vendor’s developers and other product licensees in your industry.
Maintenance
Your support contract with your vendor typically includes “maintenance.” Examine the language very carefully to be sure what it covers. It often covers free software upgrades and patches, but the devil is in the details. Sometimes vendors declare that a new major version of a product, usually after a major platform overhaul or change, actually constitutes a completely new product. Therefore, you have to pay a fee for the pleasure of upgrading or, in this case, replacing existing software. Vendors frequently release add-on modules at additional cost. Sometimes, these modules are snippets of code or subsystems that were part of the main product but are now marketed separately. Traditional vendor business practice holds that the best way to grow is to obtain new revenues from existing customers. Closely examine your maintenance contracts accordingly.
Remember also that while maintenance covers the actual software patches and releases, it almost never covers the labor involved in migrating to the newer version. Be sure to budget for these services. Depending on the scale and complexity of your implementation, this process can take days, weeks, or even months to accomplish. SaaS vendors tend to have a leg up in this area. Because they tightly control the environment, they can easily upgrade customers, often without their even knowing it.
Strategy and Roadmap
Some vendors have a clearer and more passionate sense for what the market wants and orient their product development accordingly. Others develop software in more of a vacuum and then see what sticks.
We value clarity of vision and strategy more than expansiveness. A vendor obsessed with becoming a winner across multiple scenarios probably won’t satisfy any single customer very well. Therefore, we look for focus. Does the vendor have a clear idea of which use cases fit best for its product? Has it structured its development accordingly? You should look for this, too, but remember that vendor-marketing messages tend to blur distinctions and create a false sense of omnipotence among vendor salespeople.
Be sure that your vendor truly understands asset management with respect to the following issues:
• DAM-oriented information architecture
• Workflow and feature needs for creative and marketing teams
• Domain-specific knowledge (for example, print, video, broadcast, and production)
• DAM application development
• Application technology and service trends on the Web
As contradictory as it sounds, don’t assume that a digital asset management vendor truly understands digital asset management. In fact, many suppliers, especially large vendors who sell other “enterprise” content management, have a very limited and dated vision of what contemporary enterprises want to accomplish with a DAM system. Furthermore, given the breadth of application of DAM systems, a given vendor may have little experience in your specific scenario or use case.
Viability and Stability
If strategy is one side of the vendor’s organizational coin, then execution is the other. Buyers tell us that they want stability and predictability from their software suppliers. In a fast-moving marketplace, that can be hard to find. We consider stability in very broad terms, across three general categories: product, product changes, and financial viability and M&A activity (see Figure 9.2).
• How stable is the product or service in production? Does it hiccup regularly? Where? Why? All software is buggy, but some software is worse than others. More importantly, some vendors have a habit of regularly releasing under-tested code into production.
Are changes underway or planned? Migrations frequently become painful for customers. We are generally leery of products that are about to receive a major technology refresh. The last thing you want to do after spending half a year or more on a DAM implementation is to go through a major upgrade or wholesale replacement. Of course, recently upgraded products are not always ideal candidates either. Vendors may think that they understand new platforms and technologies, but they often do not—particularly when it comes to performance. This doesn’t mean you should avoid products that have been newly rearchitected, but you should go in with your eyes open. It’s always a thoughtful reference-call question to ask about the upgrade experience, and at the same time, ask the vendor about account attrition and retention. This is not to encourage a “rush to judgment”; every vendor has some long-term and some lost clients. Your value here is knowing the why behind these experiences.
• Is the vendor financially viable, and are there potential mergers and acquisitions (M&A), disruptions, and opportunities? While this examination is necessarily subjective, there are clear markers, including cash position, sales trends, and whether acquisitions constitute a good fit. M&A activity isn’t as rampart as in previous years, but it does happen—as does strategic realignment and reprioritizing within the larger vendors. Be sure to research these facts for yourself.
