One of the most common challenges with multiple site web platforms is determining the right level of interaction between the sites. In particular, one of the most common requirements is for some kind of content sharing. The problem with "content sharing" is that it is usually given as a pretty vague requirement at first. It's like a house storage problem - you could be talking about building a second floor on your house, putting up a shed in the backyard, or buying a storage bin from IKEA. Here, I'll try to distill some of the issues and get you asking the right questions when you encounter the problem of content sharing on multiple websites.
The first thing I ask is a set of questions about the organizations that own the web sites. What is their relationship with each other? Who controls what? Which organizations prefer isolation? Which ones are open to true sharing of content and data? Believe it not, how organizations react in a content sharing environment is more important than whatever technical device you put in place to actually share it. Do organizations really want content that comes from another source? It's pretty common for me to hear "yes, absolutely" to this question at first, but then after some more talking it usually changes over to a "well, maybe."
Next, I usually ask - how much content is actually being shared? Are we really just talking about a few pieces? Putting complex sharing and synchronization mechanisms into a web architecture might not be worth the investment if the volume of sharing is low. How much content? How frequently? How many sites are involved? I try to get firm numbers in this area when devising any kind of content sharing architecture.
How is content being stored for each web site in the suite of sharing sites? Is data directly accessible across the multiple environments? Do copies of the content actually need to be made and transferred between source and destination? What are the implications of having multiple copies of the same piece of content? The basic idea of direct database-level sharing vs. copies of content transferring over a web service or feed is something that needs to be decided early on.
Does content need to be pushed from an origin automatically to a destination? If so, how is that piece identified at the origin? Is it immediately published once it hits the destination? Is a pull-when-needed approach better for the destination site? This approach allows editors more control over what they are taking from the source and what they aren't. If they are going to pull selected content from a source site, how will they find what they are looking for? How often will they be performing this action, and how crucial is it to the curation of their own content? You can't make good decisions about content control unless you fully understand the workflows used by the sites' editors.
Once a piece of content moves from origin to destination, what happens to it? Does it usually get edited by its new owner? If so, what gets edited - just the headline, the whole thing? What if the original piece of content is edited at the source - does that change then get pushed down to the destination automatically? What if the new owner has already changed it? Getting this problem sorted out is crucial to defining the correct technical solution for sharing or pushing content around between multiple sites.
When a piece of content is being viewed at a new destination, is the idea to give the reader the impression that it originated at the source or the new destination? Does the originator really just want the destination site to link back to the original source? How is the content presented at the new destination?This is often a political decision, but certainly an important one in the implementation.
Depending on the situation, the questions above may only be the tip of the iceberg for a complex and robust sharing architecture. But in most cases, getting these questions answered should give you enough information to devise an informed and appropriate solution for this all-too-common, and understated problem.