How to organise Data Centre from a SaaS perspective

[spearmint_man]

We own DC for Crowd, Confluence & Jira.

My role is implementing a SaaS offering. The deployment is sorted. I am interested in knowing how one should structure concepts of providing a dept with theses apps, some customers will be newbies with no data, some will need data migrated, weve done some of this already, but im concerned if we are migrating/adding departments in the correct manner.

My org is 60,000+ users, with departments ranging from say  100 to 5000 users.

This is a goverment body and as such each dept demands seperation, the ability to manage their own users/content etc + for me the ability to import a new customer ... or extract their data if they wish to leave this SaaS offering.

My intention is to create a crowd dir for each department, create a clone of groups and roles for that customer, as well as a default security schema etc for them. Set them up with some admins etc and then duplicate this approach for each customer. and link it up into jira/confluence etc..

I guess i want to know if this is the right approach or anyone has some useful advice or documentation they can point me at.

Im running my deployment in K8 on AWS - im a devops guy, but not an atlassian expert.....yet.

[Philip Heijkoop _ALM Works_]

Hi,

There's a lot to unpack, so I won't attempt to answer all of it, but I'll try to share what I am confident I know. Full disclosure though, I work for an app vendor, so I've seen a wide variety of set ups.

Let's start with apps, you will buy them for the entire instance, but that doesn't mean they necessarily need to be made available to everyone or even every department instance-wide. In fact, you'll probably want some governance here. If you'll permit me to use our app as an example, Structure allows you to enable/disable it from both the user side and the project data side. That means you can decide which data is and isn't accessible and which users/user groups can and can't use the tool. There's more granular control too, but we generally recommend you give full control to a user once they've passed some internal governance test to make sure they are a responsible user, since it's a powerful app and improper usage could lead to instance-wide performance issues.

Many apps have these kinds of safeguards enabled, others are only usable or configurable by a Jira admin. The actual details of implementation and governance will depend a bit on your needs and so there are no hard and fast rules. Just know that there is a lot of help out there.

For the size of this instance, I would highly encourage you to get in touch with a partner and look to hire a dedicated Jira admin (team). With this number of user and there will be deviation in needs and incoming support requests may quickly overwhelm you if you're just the one guy. I've seen Jira admin teams of up to 10 people for an instance this size, or 3-5 with an Atlassian Solutions Provider supporting in either a regular check-in or dedicated basis.

Without knowing too much more about how exactly you're using Crowd, it sounds to be in line with best practices, I just would be cautious with how literally you're duplicating between departments. Generally speaking you're going to want to balance ease of maintenance and standardizing them, with flexibility and differing needs between departments. The latter being the double-edged sword of Jira's main strength.

If you'd like, I'd be happy to talk more around specifics or recommendations if you want.

Best and good luck!

Phil

[spearmint_man]

Thanks - & sorry for not replying sooner.

I'm interested to know how I should structure crowd. If i have numerous departments, should i import all users into same crowd directory, and making project specific groups. Or is there any benefit in each organisation being in their own crowd directory?

I need them to be able to self manage as much as possible, both in terms of Jira, but also Crowd user management.

Help appreciated - cheers.