Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Page Audience: IAM designers, developers, and consumers.
Page Purpose: Describe an important design pattern for middleware services.
Document Status: Draft


Institutionally there There are many kinds of entities that we wish to identify, describe, manage, and share among multiple business functions and application systems at an institution: people, groups, departments, roles, classescourses, budgets, computers, services, programs, functions, etc. Proper management of information about these entities allows this information to be well-maintained and easily shared among all systems. A registry is a design pattern supporting effective management this kind of information.  A successful registry must deal with several issues and choose from a number of deployment options.


In a large university there are many academic and business processes supported by hundreds or thousands of IT systems.  There are a number of entities ("things", "objects") that are of interest to many of these systems.  "People" is the best example.  People are identified as users of systems, and are in system data as students in courses, holders of positions as employees, researchers on projects, etc.  It is very important to each system using person information that that information be accurate, complete, and up to date.  Since most systems share person data with other systems, it is also important to each system that person information be consistent among the set of systems with which data is shared, to avoid mismatches and confusion about correct values.  So across the large set of systems there is a need for a body of person information that is sharable, consistent, accurate, complete, authoritative, and up to date.

This same requirement set of requirements applies to other kinds of core institutional entities.  Other examples areExamples include:  organizations, courses, computer names and addresses, budgets, roles, computer-based services, groups, system privileges.  Historically data about each of these entities has been managed in its own set of business processes and systems, leading to a wide variation of capabilities regarding data flow, ownership, quality control, access, extensibility, etc.  As systems evolve the institution becomes more dependent on a larger number of systems it is appealing compelling to provide a consistent architectural approach to management of institutional entity data to better support institutional its processes. 


An effective system for management of institutional entities has a number of desirable characteristics.  Many of these characteristics are typical requirements for business systems for any business function.




Timely updates: 

 consistency, authority, access control, auditability, transparency, distributed operations, transactional control, different update and distribution methods, high volume


A registry keeps track of all instances of a particular kind of thing, i.e. a set of entities in some context.  This document is concerned with the institutional context.

Appropriate "kinds of thing" are those which have:


entries aren't removed, just marked with non-current status

appness:  put in stuff that only one app needs?