During the 1990s, industries like mine were far less complicated technology-wise.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
While the publishing industry was an early adopter of content management system technology, the business -- not user -- ran the show as far as which technologies the enterprise bought and used. At that time, industries like publishing invested millions of dollars on costly, time-consuming enterprise content management software implementations. They labored over workflows and user permission levels.
In those days, software projects were all-encompassing. Users got workstations, often with a single purpose. Projects would slog along until the workflow and tools worked to specification and the users were productive. Except for some Solitaire, there was little else to do -- and little else to use -- on a PC workstation.
But those days are long gone. The consumerization of IT -- or the democratization of IT -- where users also dictate enterprise technology trends has permeated the enterprise. Users often set the agenda on which technologies are adopted. Computing is ubiquitous, and workers are mobile. Users move seamlessly from PCs to tablets to smartphones that are replete with apps and tools. Much of this seamless transition is enabled by cloud-based content management. Workers can work on the same document in Google Drive at the office, at home and on their commute. They put it in Dropbox and forward the link to enable mobility and collaboration with coworkers.
For publishers, this flexibility is a blessing and a curse. These tools empower users to work flexibly and quickly. Unlike with traditional content management software, the learning curve is simple. But the content is mobile and potentially less secure; version control is problematic as well when multiple users can so freely make changes to a document in real time, potentially overwriting others' changes. Custom workflows and tools, built at great expense, might sit idle.
Purpose-fit tools to meet objectives
At MIT Press, we face some of these challenges. But as a midsize publisher, we have an "advantage" in that we can’t overspend on applications. We've made practical choices, emphasizing open source software to reduce capital costs and not overspend on customization. Primarily, we use the following applications:
- Alfresco Software for managing book production from manuscript receipt through bound book and final eBooks.
- Drupal for Web development
- A suite of low-priced commercial tools and open source tools for editing, print publishing, content conversion and eBook publishing.
Together, these two platforms and the associated tools do, in fact, help our productivity, manage publishing projects helpfully, and maintain a useful archive of more than 2,500 finished books and more than 300 books in progress. They also integrate significantly with business systems, passing schedule, pricing, metadata, and other information between disparate systems.
But we have many other systems to manage our content, and that's where we have to guard against increased complexity and cost, and the risk that users will stray too far from our core systems.
Because we are part of the MIT system, we have a backbone of enterprise applications that we can access, notably Dropbox for document management, Confluence for our wiki, and GitHub for software development, including the mechanisms by which we manage and stage content headed for web publishing. In addition, we have some systems I would consider legacy from a technical perspective, but they are still in use. We have used Basecamp for knowledge management in the past and still have vestiges of it, and our intranet is based on WordPress.
While this might sound like too many systems, today it isn't. We have the distinct advantage that MIT provides, runs, maintains, and upgrades Confluence for us, and pays for enterprise versions of GitHub and Dropbox. If we didn’t have that backbone, we would have to look more closely at these tools and our ability to pay for and maintain them. Regarding WordPress, we need to decide whether we will continue to host it ourselves. (The likely answer is no; we don't want to do the system and platform administration.) So, on the whole, if we were independent of MIT, we would either have to incur additional cost or cut back on the number of systems we use. We might migrate the intranet to Drupal, where we already do a lot of work, and perhaps would revisit wiki platforms, which would likely take us down the path of more open source.
The challenges for all technology teams are to invest wisely in core systems and applications, recognizing that needs are broader than what anyone or three systems can reasonably do. More significantly, users will do what they want to do. Organizations are improving at resisting the urge to build overly complicated content management applications, and recognizing as well that lightweight, free or inexpensive tools are too attractive for users to not use. While the past was replete with expensive, dedicated content management software platforms, the future, indeed even the present, clearly are not.
User expectations put onus on usability