Scaling and integrating existing disconnected drupal based sytems?

Question

We are currently planning to scale our current digital platforms to support a small number of number franchised businesses operating in different international locations.

Would appreciate a bit of help sense checking.

We are thinking about eventually effectively rebuilding our existing Drupal 7 website as a Drupal 8 site multisite installation -one installation for each business location (assuming that is the logical thing to do considering it is expected to release in the fall??).

We also have a separate Drupal 7 installation that is used as a system for accepting public submissions. I would like to upgrade to Drupal 8 rather than redevelop.

We will also be developing a smart phone app that gives users a view of their account and provides rewards etc... Currently these systems are all effectively disconnected.

We have two groups of existing users (currently residing in the two separate Drupal installations) that we need to migrate to our new system and somehow centralise.

We want to connect all of our systems (Drupal multisite installation, Drupal submission system, smart phone app and a CRM) and implement a single sign on mechanism

The thinking I am currently being sold is that we need to place the CRM system as a kind of central repository of account information that all systems can defer/sync to?

Does this seem logical/possible?

Could anyone provide any thoughts on all that?

---

just adding some more information...

The Drupal 8 part was really just based on (obviously incorrect) assumption that D8 was a more advanced stage of development that it currently is. Was trying to avoid the task of having to upgrade all of our work in 12-24 months time if it was built using Drupal 7. Maybe that is unavoidable though and needs to be factored in.

Part of the reason we were looking at a multi-site was for ease of management and administration.

We will be running sites for 9 geographically separated 'members' each of whom will have limited technical resources, plus a submission system, plus a centralised digital asset management system, plus a centralised CRM, plus our smartphone based rewards app.

Single sign on along with a central (hopefull CRM driven) view of user account information and ALL interactions is really the most important feature of what we are trying to achieve. If there is a need for a measure of technical complexity and additional resources to support that, so be it.

---

just adding a tiny bit more information...

Thank you so much for taking the time to talk through some potential solutions. I am just beginning to wrap my head around the work that is ahead of us and you have helped me hugely.

We are trying to balance efficiency and ambition for the project. Ultimately our IT staff will probably amount to at most two people to centrally manage the systems and infrastructure and one part time admin level user in each international location.

I have also been looking at the domain access module as an alternative to multisite (which I am moving further away from the more I read) https://www.drupal.org/project/domain

We've actually used Civicrm and hate it. Our 'Marketing and Comms' departments vision for the CRM is to provide a central system that provides all staff members (globally) with a view of all users (globally) and maintains a record of a logged in users interactions across our entire business (we would seek to integrate the CRM with other external systems like submissions, ticketing, retail POS, ecommerce etc...) it would also provide us with advanced integrated comms, segmentation and targeting tools. We'll likely need lots of custom code and likely an API of some sort too.

I guess the thing is that it's not just Drupal authentication we need to be able to handle. We need users with an account to be able to log in to lots of services or applications (in an ideal world that would include a logging in and viewing account info via a smartphone app, logging into onsite wifi, logging in to some ecommerce system) at every point information is being gathered and collated to provide business intelligence.

As I say there is a fantasy/reality scenario here. As a business, there are things wee need soon (more websites with a single sign on implementation for example) but rest of the tools we want are fairly technically complex to deliver and not exactly matched by the resources that are currently available. We acknowledge that but there is a requirement for us to plan for integration of tools on this scale at some point in the not too distant future.

Answer 1

A couple of things to consider:

1. Unless the sites are very simple, or you are intending to use the project as a way to contribute to Drupal 8, Drupal 8 is not yet ready (as of this post) for production use. You may find yourself doing a lot of bug-fixing, coding, porting of contrib modules etc. But if that's what you want to do, it will be a great boon to the community!
2. Multisite has advantages and disadvantages, there are many blog posts and such discussing this and I'm sure you've probably read some of them. The biggest factors that influenced my decision (we use multisite) were:
   • You only have to update the core files once each time
   • You only have to keep one set of contrib modules up to date (sites/all/modules)

If you're making sites for different clients I would caution against multisite because it means you have to update core for all of your client sites at once. In most cases this is fine, but what if something goes wrong? All of your clients will be on your back at once clamouring for a fix and you'll spend more time calming them than fixing the problem, not to mention that's a bad experience for all of your clients, not just one.

Nobody is immune from issues, even if they only happen once in 5 years.

I understand you're working with franchisees... but they're still effectively clients.

Here's the thing - you don't need to share the code-base in order to share certain tables such as the user table (that and a few others when shared make for really easy SSO).

Everything you're suggesting can be done. But, if it's only about accounts, I would keep separate code-bases (doesn't cost any more RAM or CPU as far as I know, just a bit of HD space), and share the user table (and maybe roles).

---

[Response to extra info:]

Drupal 7 will be around for years yet, until there's a release Drupal 9, in fact, you will have to upgrade eventually, but now is not the time unless the sites are very simple, and these do not sound like simple sites.

I had further thoughts about my answer above, and the multiple client situation can work as long as you've got a good rollback method for upgrades and your IT staff are happy to do upgrades outside the hours the sites need to be operational. The biggest issue with that is when your different clients or members are in different time zones and have different needs regarding down-time.

What sort of interactions are you hoping to log? Sounds like you'll need some custom code for that (duh). If the member sites are all carbon copies you should be able to reuse it across them.

Drupal has a CRM plugin called CiviCRM but it's not really set up for commercial purposes. I'm guessing you're using something like SugarCRM or Zoho or SalesForce, you will have quite a large task on your hands. One of Drupal's core abilities is to manage users, what do you want the CRM to do?

Would it be enough to have your main repository of user account information in Drupal and then push that repository and all relevant events to a CRM? What about an event tracker like Google Analytics or Woopra?

If you're being sold multi-site with a single user repository as an idea, I think Drupal should be the repository, because then you can do this.

---

If you were doing all your user management on Drupal, and all you need is a repository of credentials for logging in to other systems, consider LDAP (docs, project). You can push all changes from Drupal to LDAP and then have your other systems read credentials from there.