Almost every week, a new technological innovation comes to market, promising to save publishers money, streamline workflow, reduce administrative burdens or reach more readers.

These innovations are diverse, but they share one thing in common: each promises to make our lives easier.

The unique selling propositions vary. Some offer easy enhancement of ebooks (CircularFlo, Beneath the Ink). Others let you conveniently mark up your manuscripts online (FutureProofs). Some offer to improve marketing (NetGalley).

Still others promise to reduce back-office administrative labor (my own Bibliocloud). There are, additionally, tens and possibly hundreds of offerings promising to take the pain out of social media campaigns, mailing list management, editorial workflow, production and schedule management, online galley review, e-commerce, print-on-demand (POD), rights sales—you name it.

But here’s the rub: These solutions usually get developed in isolation, with little consideration for where they’ll each fit into their new customers’ existing technological ecosystems. And that’s hardly any surprise. With the myriad systems publishers use, how can a developer accommodate them all?

A prospective publishing client might have a distributor whose stock management system is an old AS400, alongside a Drupal customer-facing website, with Microsoft Navision for finance and Klopotek for metadata management.

Another publisher might have a distributor that uses an online data warehouse and a Magento website, with SAP for finance and spreadsheets for their metadata and scheduling processes.

How can a developer working on a new product or solution for either of those clients know precisely which integrations to plan for? And anyway, the developer is focused on building her new product to be amazing on its own merits. Legacy system integrations come later, right?

Wrong. Almost any new service is great, in isolation. But the real value—and the real pain—comes when it’s integrated into publishers’ own unique IT ecosystems.

Say the exciting new service that you want to incorporate into your business is for making enhanced ebooks. (There’s more than enough debate about the wisdom of that decision, but let’s take it just for the sake of argument.) It will require more content, more files, more workflow to create the new assets. And that opens up a slate of important questions: Which systems will be impacted by this new aspect of your business? Your metadata management system, your ONIX output, your editorial-production workflow, your scheduling software, your rights and permissions system and your finance system: Will they play nicely with your new toy?

What about something publishers might consider more sensible, like POD, a service that promises to radically simplify your stockholding requirements—how will that integrate with your distributor’s existing systems? How will you represent the applicable rights in your ONIX feed? What about sending the stock status to retailers? What about the additional printer scales?

If you’re not very careful, your supermarket sweep of shiny new services will turn into a major administrative overload as you try to stitch together a growing array of disparate systems. Doing so is almost always costly, and as I’ve written before, publishers must carefully weigh those investments against the returns that the new strategy they’re meant to support is likely to generate. Otherwise publishers end up becoming middle-men between two or more system providers and experiencing the worst of all worlds as a result—feeling the most pain and being the least equipped to ameliorate it.

So, in addition to listening critically to pitches for how any new service might make one isolated dimension of your publishing business easier, here’s what you need to ask of developers:

What is your track record for adapting to changes in the supply chain? Which systems do you integrate with? What was your process for determining the data formats accepted by the other systems yours is built to work with? Do you accommodate two-way data transfers? Could I see your API documentation please? In previous projects, who changed their code to accommodate the integration—you or them?

Developers and their fancy boxes of tricks often promise to make publishers’ lives easier, and of course their solutions can indeed turn out to do just that. But before things get easy, publishers have to confront the hard part first, and determine how well any new addition will integrate with all their other labor-saving systems.


    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Menial publishing jobs are destroying our future
  4. It's us in the industry who need to be able to code
  5. A manifesto for skills
  6. Learning how to code, the long way around
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Sara O'Connor to join the team!
  12. And now we are five
  13. Prizes galore
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. A publisher’s guide to APIs
  27. What publishers need to know about Ruby on Rails
  28. How APIs can make publishing more efficient
  29. A day in the life of a programmer
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Don’t outsource your publishing business away
  33. Who has the balance of power over data?
  34. Inbound marketing
  35. The business case for going direct
  36. Why publishers must use direct sales
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. ONIX Changes
  44. BIC, Thema and artificial intelligence...
  45. How to create a catalogue automatically using ONIX and InDesign
  46. Skills

  47. Embrace the code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. A taste of code
  51. Strategy

  52. Rejuvenation
  53. Why ‘easy’ publishing solutions hardly ever are
  54. The right tool for the job
  55. No computer system can fix a broken publisher
  56. Five things I've learned since moving into enterprise product management
  57. Managing expectations
  58. Start with Why – How to refine your publishing mission
  59. The real price of a strategy shift
  60. Technical debt
  61. Decisions, decisions
  62. Creative industries and the division of labour
  63. A company of one's own.
  64. Responsibility, Authority, Capability
  65. Sometimes, size matters
  66. The search for publishing's holy grails