Uncertainty, meet modularity
Publishing organisations should look to adopt modular infrastructure and modular business models so they can experiment, writes Brian Cody
Uncertainty is something we're all living with now — uncertainty about the Covid-19 pandemic timeline, uncertainty about the economic impact on universities and associations, uncertainty about what the long-term effect on the academic publishing industry will be.
Before this pandemic, we already had substantial uncertainty in our industry, specifically about what business models would be viable for academic journal publishers given the ongoing push towards open access (OA). It's been unclear for years what the transition to OA will ultimately look like, with many experiments and new initiatives emerging all the time. Recently, it has felt like new journal publishing business models are being introduced by the week: read-and-publish, publish-and-read, pure publish1, subscribe to open2, consortium agreements, membership models — and the list goes on. Which of these OA business models will be keeping publishers afloat in 5 or 10 years, and which will have proved to be unsustainable or short-sighted? What OA business models that we haven’t even thought of yet will be important in 10 years?
Spoiler alert: this article does NOT include a functioning crystal ball to answer these questions. My apologies.
Instead, this article looks at how publishing organisations can position themselves to efficiently experiment with, abandon, and adopt emerging business models over the next 5 to 10 years through a modular approach to infrastructure and building an Agile organisation culture.
Modular business models
Modular design 'subdivides a system into smaller parts called modules... which can be independently created, modified, replaced or exchanged between different systems'.3 This is a common approach used in the manufacturing of products like cars, computers, and even entire office buildings. Being able to upgrade a part (e.g., a more powerful car motor) or add additional components (e.g., more computing processors) without all the other components also needing to change is an efficient and flexible design pattern, and has proven to be a competitive advantage for companies such as Volkswagen.4
Outside of physical manufacturing, the idea of modularity as a competitive advantage has been explored academically since at least Herbert Simon5, who introduced the idea of 'near decomposability' to demonstrate that complex systems that have stable sub-systems (or modules) allow the system to evolve and operate more efficiently than systems that do not have these sorts of sub-units (aside: I'd recommend reading Simon’s 1962 article just for the charming thought experiment featuring two watchmakers named Hora and Tempus). The idea that new business units could be added or altered without incurring coordination costs across the rest of the organisation has been highlighted as part of the competitive advantage of companies such as Amazon6.
In the publishing industry, many are already familiar with the experience of modularity, or the lack thereof. For example, if a publishing organisation wanted to launch a new journal with a different workflow (e.g., open peer review, or publishing individual articles as they're available rather than issue-based publishing), would doing so require coordination across the organisation? Would the new project need to utilise the same software, people, and processes, or could it be implemented with different software or a different workflow without sowing confusion and adding complexity to the existing processes?
Modular infrastructure
For many academic journal publishers, the extent to which they can accommodate modularity is often seen as enabled (or hindered) by their software infrastructure. Does your publishing solution support open peer review? If just one journal wants to send/receive data from a new machine learning service, does that impact all the journals that will NOT use that service?
There is a classic (and relevant) tension in software design and software purchasing decisions about whether the software should do everything the organisation needs in one place ('software suite') even if each piece is not ideal, or whether to utilise multiple separate software applications that each excel in their domain, with the downside that you have to learn multiple systems and keep them talking to each other.
This is the 'best-in-suite vs best-in-class' problem, where the 'suite' (an all-in-one software solution) is contrasted with discrete applications/products. There are pros-and-cons to both approaches – but when faced with lots of uncertainty and a rapidly changing business environment, taking the 'best-in-class' approach offers many competitive advantages that outweigh the coordination and management costs of using multiple pieces of software:
1. Upgrade frequently: Migrating to a better enterprise software suite is an initiative often planned and executed over years, which can slow the pace of innovation. However, migrating to or from a software application for a specific need normally takes weeks or months, not years, so more modular organisations can use the best tools available at a very rapid pace. Similarly, compartmentalised software applications often introduce more rapid upgrades because the application components are discrete. Using multiple 'best in class' software applications can move publishers away from the lengthy RFP model (typical for larger software platform purchases) to be able to iterate on and optimise operations more quickly.
2. Culture of integration: Using distinct products for specific needs does require organisations to move data between those products. While this may be a deterrent initially, as organisations build expertise and capacity for moving data it can become a strong advantage. Data migration capabilities enable organisations to more easily adopt and integrate new third-party solutions. This constitutes a positive feedback loop, where transferring data between products allows organisations to reap the benefits of new third-party solutions, which in turn increases the organisation's competence with moving data, which then lowers the cost of using further third-party solutions, ad infinitum. This can empower organisations to more easily adopt new tools, rather than having to wait for equivalent functionality to be added to their 'software suite'. The choice of software is important here – some software products make it very easy to integrate with third-party applications.
3. Low-cost experiments: As new publishing models, new software, and new services emerge, organisations with more modular infrastructure can quickly ramp-up new journals or pilot projects without high up-front costs. This rapid experimentation is coupled with the ability to rapidly abandon projects without the sunk cost fallacy7 slowing the critical evaluation of a project. Imagine a publisher trying a new crowdfunding approach to fund an OA journal: if it took an 18-month effort to get the crowdfunding project off the ground but didn’t look promising after a year, it might be tempting to give the pilot another six months to see it it pays off – but if it took two months to launch the crowdfunding project and didn’t look promising after three months, it would likely be easier for everyone involved to decide to abandon the project quickly.
Conclusion
I started writing this article just before the Covid-19 pandemic response really took off in the United States, and I had to shift my attention (as many of us have) to adjust to the new normal of working from home within a pandemic with no clear end in sight. When I came back to the unfinished article, I felt it was more timely than ever: that how well-equipped a publisher is to respond to uncertainty will be a major factor in their growth and survival seems all the more believable given the massive uncertainty we’re all living in right now.
Modularity is one approach publishing organisations can take to increase their agility and their ability to pivot. As uncertainty continues to be a major feature of our industry's landscape, publishing organisations should look to adopt modular infrastructure and modular business models so they can experiment – and quickly abandon business models that prove unsustainable.
Brian Cody is CEO and Co-founder of Scholastica
References:
1. https://scholarlykitchen.sspnet.org/2020/02/20/pure-publish/
2. https://scholarlykitchen.sspnet.org/2020/03/09/subscribetoopen/
3. https://en.wikipedia.org/wiki/Modular_design
4. Wilhelm, B. (1997), “Platform and modular concept at Volkswagen – their effect on the assembly 57 process”, in Shimokawa, K., Jürgens, U. and Fujimoto, T. (Eds), Transforming Auto Assembly, Springer, Berlin, pp. 146-156.
5. Simon, Herbert. “The Architecture of Complexity”. Proceedings of the American Philosophical Society, Vol. 106, No. 6 (Dec. 12, 1962), pp. 467-482
6. Girotra, K. and Netessine, S. (2014), The Risk-Driven Business Model: Four Questions That Will Define Your Company, Harvard Business School Publishing, Boston, MA.
7. https://en.wikipedia.org/wiki/Sunk_cost#The_fallacy_effect
