Here is a LONG answer to your multi-tenancy architecture question, which
has been keeping us up late at nights as well.
We are in the middle of a multi-tenancy design project for the
university, and came up with this plan, which is up for approval right
now:
A UNT Customer company contains all imported customers from PeopleSoft,
organized by department (160,000 active or 320,000 total records)
- Some summaries, CTI, assignment rules will run against all customers
in this container, and will set Owner on Department
- Every login that uses LDAP authentication will be in this container
- Every login will only have permissions like Incident Viewer and/or
Submitter, Asset Viewer, and KMSAC-KMSUsers, but they do require them...
- Unfortunately, because of some poor design decisions in the ITSM 7
app, everyone needs a User record as well as CTM:People record just be a
customer; they have to have these explicit permissions assigned to them
or they can't even use the Requester Console
- Even less fortunate, from the same design "process," is the fact
that even in a Submitter Locked system they have no or limited access to
update their incidents as opened from their customer email
notifications, because there is no submitter = requester mechanism like
previous ITSM releases
- NOTE: All tickets created for UNT Customers are visible to ANY
support staff member
- WORSE: ANY UNT Customer, because they ALL have access to that
container, can see them too; unfortunately, the new requester view of
the Incident give them access to search the entire incident table in a
way that was not possible in the ITSM 5 or 6 Requester views; oops!
We have maybe 30 central computing support teams and 25 distributed
support areas - each gets its own private company container
- Each company is able to have their own CTI, templates, decision
trees, etc.
- Each company can have as many support groups as they want - right
now most have only one, but the library has almost a dozen
- Support staff members get a new, unique login for their home company
with a local (non-LDAP) password
- If necessary they _could_ have a second login homed in another
company, or even with a different permission set, but so far we don't
need any
- Each support staff member is given access to the UNT Customer
container so that they can open a ticket for ANY customer
- In addition to the global CTI etc., they see UNT Customer CTI, and
their unique Company CTI or decision trees
- If they open a ticket with an INTERNAL company login name as the
customer, with their company as the Owner, it is completely private
within the company container
The problem comes when support staff members want to transfer tickets to
groups in companies to which they have no access. Here is what makes
this workable:
A UNT Ticket Transfer company contains no customers, no support staff
accounts, no CTI or rules, only support groups
- Each central and distributed support company that does business
outside its container (all of them) has at least one support group
defined here
- Each support staff member (or a subset if they want) has access to
the Ticket Transfer company, and should be a member of their exposed
support group
- As a result, each company has a "drop box" in the Ticket Transfer
company that members of other companies can see and reassign tickets to
- Tickets placed there show up in the support console just like
tickets in the internal company support groups, through group membership
- The first action of support staff is to "take ownership" of
tickets in the transfer group - several functions don't even work in the
Incident module, like setting Status = Pending, if you are not the
actual Assignee
- NOTE: If a private ticket is assigned to a group in this
container, it is no longer private - all with access to Ticket Transfer
can see it (~300 support staff accounts)
- If a ticket MUST stay private between two groups, it MUST be moved
from one company's internal support group DIRECTLY into another
company's internal support group, NOT through the Ticket Transfer
company groups
- That requires unlimited access to see and select the other
company's group, or, explicit permission into the other company's
container
- Even if you assign a private ticket to another company's group,
they may still not be able to see it!!
- Changing the value in the "Incident Service Type - Company*+"
field is the key to making a private ticket visible to another group
- Only our Information Security team is expected to need/have
this kind of permission, to assign remediation requests
- The distributed company needs no explicit access to return the
ticket to Info Security - they use "Set Assignment using: Current Owner"
Our most recent development is to add a customer company for each
distributed area that wants to make custom Summaries available to only
the customers in that department
- We should be able to add access to the distributed customer company
to a subset of UNT Customers members based upon Department values
- The distributed support area company will also "own" their custom
customer company - not many will want this, but it is possible for those
that do
- The requester console will then display global Summaries, UNT
Customer company Summaries, and local customer company Summaries as well
- Still testing to see if this actually works correctly
- We had thought that this would also affect how the Service Request
Management application presented services to customers; now that I have
heard the ludicrous price tag they plan to attach to the "enhanced
Requester Console" application, it may be financially out of reach for
most Remedy sites
Our information security folks want us to limit unrestricted access to
administrators and maybe one or two others, approved through them, since
they can SEE anything. Note that just because they can see it, in our
experience that does not mean that they can do anything with it.
I have some charts of this, and we are using it to demonstrate scripted
ticket scenarios where navigating the company structures for public and
private tickets is part of the process. I welcome any critique or
suggestions, since we are still building out a sample set of
organizations, CTI, customers, etc., and testing it.
Christopher Strauss, Ph.D.
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Molenda
Sent: Wednesday, February 14, 2007 9:23 PM
To: arslist@ARSLIST.ORG
Subject: Implementation Q> ITSM 7 and "Shared People" as 'Generic
Contact' Company
Hi fellow ITSM 7'ers;
Implementation Q, that has BMC Stumped now, and honestly myself because
I thought (whoops) it should work as I expect instead of...
This is a OOTB (Out Of The Box) ITSM7 installation (ITSM patch 2 in
addition) with all modules (Service/change/sla/cmda/...)
Scenerio:
Infineon has 44K employees, which we would like to represent to the
"modules" as a "Generic Contact Company"
OK this works as expected, in Multi-Tenancy mode, however the support
staff need access permissions to the "Operating Company-1" and the
"Generic Contact Company". Fair enough, assumption to this point, works
as expected!
However when "Operating Company-2" needs to share these same "people
resources" they also must have permissions to the company, which is OK,
until... (tick tock)...
Now "Operating Company-1" can see "Operating Company-2" tickets, etc.
This is because the ticket permissions are set based upon the "Company"
of the "Customer/Contact/Classification" companies! Seeing as that one
"operating company" is HR with sensitive ticket data this is not
acceptable...
Not to mention that the assignment rules use the "Customer Company" and
not the "Classification-support company" is also becoming an issue.
OK I know that I nod off at times in classes, but this has gotten
myself, Materna consultants, and Remedy Support now escalated into 2nd
level...
Hopefully there IS a light bulb in the box, but ours is simply burnt-out
and needs replacement... (who has that flashlight??)
We cannot import the people "multiple times" because of web-interface
and the unique key in 'user' for the login, and, and, and, and...
I hope this makes enough sense, because our brains are fried on the
topic now, and maybe (hopefully) we are lost in the forest of trees so
to say...
Thanks-n-advance;
HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS
PA
Tel: +1 408 503 2701
Fax: +1 408 503 2912
Mobile: +1 408 472 8097
[EMAIL PROTECTED]
Quality begins with your actions.
****VISIT US AT: www.infineon.com <http://www.infineon.com/> *****
"This e-mail and any attachments are confidential and may be subject to
legal or some other professional privilege. They are intended solely for
the attention and use of the named addressee(s). If you are not the
named addressee(s) you must not use, disclose, retain or reproduce all
or any part of the information contained in this e-mail or any
attachments. Any unauthorised use or disclosure may be unlawful. If you
have received this e-mail by mistake, please inform the sender
immediately and delete it and all copies from your system and destroy
any hard copies of it."
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
