Recursive Arguing II

Yesterday, it was about how to pull a hot fix.  This time it was about who is an admin for a particular provisioning tool and involved not just me and the 3PAO but the PMO as well.

PMO (after much back and forth previously): We sent them the list of internal administrators for the password tool.

Me: This spreadsheet has internal employees.  But they're acting as administrators for their testing and sales companies.  Not as administrators of the tool.  Are you sure this is what the 3PAO wants?

3PAO and PMO: That's what we want.

Me: You want sandboxed administrators who can't create administrators for companies that don't exist in reality but are there to demonstrate functionality to potential customers.  Additionally, that sandbox means they are scoped within their fake/faux company and have no impact on other customers whatsoever.  As long as we're clear.

3PAO: We're not clear.  Those are superusers, right?

PMO: They are administrators.

Me: We don't have superusers.  They are administrators within the web application for their company.  They are not administrators of the password tool.

3PAO: We don't get it.  They're internal users and they can provision internal users for the application.

Me: Yes.  The web application.  Within their fake company.  There are two things being considered here.  1.) the web application: our employees can use it just like an external customer.  If I was Bob's Widgets I would have an administrator.  That administrator would determine who in my company could use their seats.  If I was the administrator for our company - we can eat our own dog food - or for a fake company we use to show potential customers functionality I could only add users for that fake company or our company.  2.) the password application or service layer - it's really both.  There are internal people who have access to that tool and are administrators.  They can create administrators for companies/customers who buy our tool.  It seems to me that's who you care about as they could add themselves to someone else's membership.  Like the person who created this list of internal administrators for the application in the first place.

3PAO: Exactly.  The people on this list can create an administrator for company X (a company to which they don't belong).

Me: NO.  They can only create users within their own company.  They are not internal administrators of the password tool/service, they are administrators for their instance of the application.

3PAO: That's the same thing...

PMO: Wait...maybe not.

Oh...it went on and on with me drawing pictures and flowcharts and providing concrete examples of the data using internal groups and employees and fake Doctor Who-based examples.  The end result is a meeting with the internal person who created the list so I can get a new list of the three or four people who code or admin the password tool who could actually cut across company lines.  I don't think the concept of Service Oriented Architecture has embedded itself as deep and wide as I would expect.