?

Log in

Why might you want Alfresco's Cloud-Style Multi Tenancy on-premise? - Nick [entries|archive|friends|userinfo]
Nick

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Why might you want Alfresco's Cloud-Style Multi Tenancy on-premise? [Sep. 19th, 2013|12:24 am]
Nick
[Tags|]

In part 1 we looked at what Alfresco Multi-Tenancy (MT) is, and why you might want to use it. In part 2, we looked at how collaboration makes a strict one-tenant-per-user model no longer work well, and saw how the Alfresco Cloud has solved this to permit efficient and effective collaboration.


Let's have a quick review of the situation, to remind ourselves how it works:

Each team / department / company / etc has full and complete control and administration over their tenant (as identified by their email domain). When they need to collaborate with someone from outside of their tenant, they invite them in for that one site. The person invited in retains full control of their own tenant, but gets the limited rights given to them in the sites in invited tenants. They can work with others on documents in those sites, collaborate, discuss, comment, but not pierce the veil of the security or protection


Now, that sort of thing can be done without the need of Multi-Tenancy. Alfresco is heavily customisable and extensible, and allows you to override or replace all sorts of parts. If you know what you're doing, it's perfectly possible to achieve the same thing in a single tenant setup. It's not a quick job though, and you'll need to do things like:
  • Define your own way of recording which "virtual tenants" people can access, and what belongs to what
  • Override various People searches (services and webscripts) to check/filter by that
  • Override the Category/Tagging services, along with various webscripts, to give each "virtual tenant" their own tag cloud
  • Override the default permissions, to be more restrictive
  • And a few other bits too...

OK, so it can be done, what's the problem? Well, a few things, including:
  • The initial work takes a while (reviewing then coding), which means less other work
  • Upgrades are slow, as you often can't cleanly override the bits you want to, so you often have to port your code forward + re-review
  • Testing and Validating takes longer, as there are more "moving parts" (so to speak)
  • You have to write custom reports to list who has access to what, so that access reviews can be done, rather than just listing tenant users
  • You have to do the work, rather than getting it included in your Enterprise subscription!


I know for a fact that at least one company would prefer to use Cloud-Style MT on-premise, rather than achieving the same thing with permissions + customisations (mine!), but I strongly suspect we're not the only ones. In fact, I'd rather suspect that there are huge numbers of potential customers out there who stuck Alfresco off their "potential systems" list early on because of a lack of such support "out of the box".

Let us consider a typical collaboration environment, which could easily be different departments within a large organisation, or small companies working together, or a mixture of big company departments and their outsourced providers helping:

In this situation, Users 1 and 2 work for the main company, but invite in two different smaller agencies to help them out with different things. We could even imagine a case where Users 3 and 4 collaborate together, without the others!

How about some simple cases of this setup?
  • Two different departments use the same install of Alfresco, but want complete control of their own spaces. They need to use the same marketing agency, and sometimes both departments and the marketing agency need to work together on an advert
  • Three different departments each have their own intranet, but also all work on the internet site. They need to collaborate with external designers and web agencies on sites relating to their joint external website, as well as each department with just the agency for their respective intranets
  • Operations and Fixed Fee both have their own areas, but they sometimes need to work with Legal and Purchasing, who both have their own areas too

I'm sure I could go on with ideas involving federated companies, or other cases with strong inter-departmental divisions but an increasing need to collaborate across them on certain things. Now, let us consider a few cases where there are many companies, who might all want to share one collaboration system, but currently Alfresco Enterprise won't fit their needs because of a lack of the Cloud Style Multi-Tenancy.

Business Incubator. Needs to be common sites to submit quarterly reports, as well as for general discussions about the space. Some companies will collaborate with each other to win funding, so need shared sites. In other cases, companies are secretive about their partners, and don't want to leak information about who they are working with. Not only do sites need to be private, but they need independent Tags and User lists to prevent one company being able to find out things on another one by checking tags or doing people searches.

Pharma. Pharma A have WonderDrug A, Pharma B have WonderDrug B, but both are also working together with Pharma C on WonderDrug Z. All 3 use the same DM CRO, A and C use the same PV provider, B and C the same MW provider while A do their MW in-house. On WonderDrug Z the three pharma companies want to share their data, but A doesn't want B or C to know who they use for their in-house MW to prevent poaching, no-one wants anyone else to know their tagging schemes, and the DM CRO shouldn't have access to everything even if they work with everyone. (You can do this setup with permissions, but as previously mentioned it has notable upgrade costs)

Banking. The Legal and Compliance teams need strong separation between their areas and those of the rest of the business. IBD and Equities need to be able to prove that the Chinese Wall remains unbroken. All of them need to collaborate on the Charitable Works project, and some of all of them need to offer input on the re-tendering of the catering contract. Passwords need to change often, and the idea of having multiple logins won't go down well.

I'm sure there are a number of other cases too, where the need for strict separation between Tenants is required most of the time, but controlled access between them to collaborate is needed in others. Those were just the three that first sprang to mind. In all 3 cases, unless you have a very deep knowledge of Alfresco, you would do an initial evaluation of the product then reject it as unsuitable, since the feature isn't there out of the box. How many lost deals are there out there from this feature not being present? How many possible deals never got into an Alfresco prospects list, because the lack of collaborative MT was spotted before anyone talked to sales or a partner? How many times have organisations really wanted to open-ness and community that comes with Alfresco, but had to go for a different solution because of this one missing feature? I'm going to say the answer to all of those is "rather a lot"

The crazy thing about these missed sales, these missed opportunities, these skilled Alfresco customers having to roll the solution themselves, is it's not some impossible new feature that would take man-years for Alfresco to add in. This is a feature that Alfresco have already written, tested, documented, and supported for getting on for 2 years! This wouldn't be some new area to develop, this is something Alfresco already support, and effectively support twice!

How much work would be involved in migrating this existing feature over from Cloud to Enterprise? Well, some parts of it are already done. As mentioned in this 4.2 blog post, the new Public API on 4.2 uses cloud-style URL patterns, eg http://localhost:8080/alfresco/api/-default-/public/cmis/versions/1.1/atom
The -default- in the URL is an explicit tenant selection, which is the first step in the move away from the old-style implicit tenant selection. What else? Well, there would be a lot of testing involved - Alfresco Enterprise has a much wider set of supported stacks/platforms than Cloud. Coding/Merging wise, it wouldn't actually be too bad, certainly a lot easier than some of the other Cloud -> Enterprise merges that have happened of late. Documentation would need updating too, and probably some compatibility layers that maintain implicit tenant selection on old-style URL patterns.

All in all thought, it's not something that could be knocked out in a couple of i-days, but it's not a huge undertaking, much smaller than others recently. It would reduce support and maintenance costs for Alfresco, by reducing from 2 to 1 the number of MT platforms supported. It would greatly reduce the support/maintenance costs for those currently forced to implement their own system. Perhaps much more importantly, a huge number of new sales opportunities would arise, and arguably a number of whole new sectors would suddenly be able to consider using Alfresco. I may be a little biased, but I'd say that's well worth going for!
linkReply

Comments:
From: jamilnour
2015-08-26 02:05 pm (UTC)

Alfresco did it or not?

Hello,

Very nice set of articles with a good explanation.

My question is: do you know if Alfresco did the move or not?

The date of the article is 2013 so I hope they did it even I did not find anything about the subject with the latest Alfresco versions

Best regards
Jamil
(Reply) (Thread)
From: gagravarr
2015-08-26 03:49 pm (UTC)

Re: Alfresco did it or not?

Nope, sadly, they have thus-far refused to put the Cloud MT stuff into the on-premise (Enterprise / Alfresco One) version :(
(Reply) (Parent) (Thread)