Authority ImplementationStanford University

Lynn McRaeCSG Presentation

September 18, 2002

Contents

1.Background

2.Design & Implementation Strategy

3.Rationalization of Function

4.Financial Authority

5.Roles

6.Future

Background

• Rich, integrated, highly customized mainframe systems

• Complete administrative systems replacement

• Summer 2000, Central/Enterprise authority

• Timing and project ties

• Full year lead time

• Three phases 6 months apart – Student, HR, Finance

Design & Implementation Strategy

• Use of Registries architecture• Ties to Person (identity, affiliation, privgroups)

• Ties to Organizations (scoping, distribution model, re-org resistant)

• Ties to Workgroups (roles)

• Space Dogs• Mix of technical and non-technical

• Vetting architecture

• Vetting design

• Buy-in to high level integration approaches

• Need queen (or king) of project authority

Rationalization of Function

• High level approach

• Role of naive inquirer

• Strong mapping into local auth layouts

• System levels vs project controlled levels

• Only see what you have to grant

Functions (cont)

• HR (15 functions)• Benefits• Payroll• Time/Leave• Faculty• Labor Costs

• Student (29 functions)• Prospect/Applicant• Course• Finances• Financial Aid• Records

Functions (cont)

• Financial (73 functions)• Accounts Payable• Accounts Receivable• Fixed Assets• GA/General Accounting• GL/General Ledger• Labor Distribution• Purchasing

Financial Authority

• Much more complicated requirements; no “practice” implementation

• Project has been deferred one year, but requirements continue to evolve and have implementation ambiguity

• Multiple central offices represented

• Needs much deeper understanding of business units of meaning

• Change from Authority entities to Organization/Financial entities

• Capture true chain of authority

Roles

• Financial Approval roles

• School/Department super-users

• Organization roles, assigned outside the Authority Manager

• Department defined roles

Future• Currently authority is directed only to

specific consuming systems

• Good use of XML for privileges document

• Underlying infrastructure evolution• PKI• Events/messaging• Web services

• Publishing authority information to the infrastructure• As callable service• As directory artifacts• Supported in other infrastructure services