Saving Enterprise Data from the Client/Server Grinch

This paper was presented at the 1995 CAUSE annual 
conference. It is part of the proceedings of that 
conference, "Realizing the Potential of Information 
Resources: Information, Technology, and Services--
Proceedings of the 1995 CAUSE Annual Conference," 
pages 3-7-1 to 3-7-11.  Permission to copy or 
disseminate all or part of this material is granted 
provided that the copies are not made or 
distributed for commercial advantage. To copy or 
disseminate otherwise, or to republish in any form, 
requires written permission from the author and 
CAUSE. For further information: CAUSE, 4840 Pearl 
East Circle, Suite 302E, Boulder, CO 80301; 303-
449-4430; e-mail info@cause.colorado.edu.


SAVING ENTERPRISE DATA FROM THE CLIENT/SERVER 
GRINCH

John D. Porter
Susan D. Moore
John J. Rome
Arizona State University


ABSTRACT
     
In the world of client/server technology, where 
enterprise databases are distributed, how do 
postsecondary institutions keep from losing control 
of their data sources?  One university's answer was 
to create an enterprise data infrastructure to 
ensure the integrity and integratability of 
enterprise data.  The data infrastructure serves as 
the "hub" of a portfolio of distributed enterprise 
applications.  This paper describes the 
implementation of the first subject area of the 
hub, the Affiliate Management System, which 
contains enterprise data on the organization's 
customers.


ASU'S COMPUTING ENVIRONMENT

Arizona State University is a Research I, multi-
campus university consisting of three campuses in 
the Phoenix metropolitan area.  Total enrollment 
exceeds 45,000.  The administrative computing 
environment centers around IBM 3090 MVS 
architecture.  The student information system, 
developed by ASU, is an on-line and batch 
application using a large integrated data base 
(IDMS).  The human resources system is a purchased 
package running on DB2.  The university's financial 
system is also a purchased package running on IDMS, 
but migrating to DB2 this year.  Another IBM 
product supports electronic mail and FOCUS 
applications.  FOCUS, which was used for end-user 
reporting and departmental applications, is being 
replaced by client/server applications.  The first 
client/server implementation was a data warehouse.  
ASU is exploring other client/server applications 
in a re-engineering project involving the student 
information system.  Client/server applications use 
Sybase on a UNIX server.  


ASU'S DIFFICULTY IN IMPLEMENTING CLIENT/SERVER 
TECHNOLOGY

Implementing client/server technology at ASU proved 
more difficult than promised by industry.  
Client/server technology is less reliable, secure, 
and timely than its mainframe predecessor.  
Networks add new layers of complexity, and 
monitoring performance and tuning of servers is 
imperfect.  The result is that for complex 
organizations like ASU, quickly moving mainframe 
legacy systems to client/server on a major scale 
may be too difficult. ASU's information and 
technology managers came to this conclusion re-
engineering the organization's student information 
system.  Given the problems in piecing together the 
new and old technology, ASU realized that mainframe 
systems were going be around a long time, 
coexisting with client/server applications until 
the industry solves some of the problems inherent 
in distributed and shared computing. For ASU, 
slowing the pace of client/server development 
provided data administration and the information 
technology mangers the time to devise a solution to 
the critical data problems posed by client/server.


THE NEED FOR AN ENTERPRISE DATA INFRASTRUCTURE

ASU's information managers view client/server as a 
desirable computing solution because of the 
potential for new and improved services for less 
cost (see anticipated client/server benefits in 
Table 1 below).  However, client/server also raises 
many technical, data and security risks. One big 
risk is that distributed databases and systems will 
degrade the integrity of enterprise data and lessen 
the ability of the organization to integrate data 
between computing systems.

Benefits of Client/Server

  * Flexibility
  * Potential of Technologies
  * Scalability
  * Increased Productivity
  * Long Term Cost Savings

These concerns lead ASU's information managers to 
conclude that the organization needs a 
client/server enterprise data infrastructure (EDI).  
The vision of EDI is that ASU captures the critical 
enterprise data elements required by multiple
business processes in a single data model and 
database.  EDI functions as the hub of a portfolio 
of mainframe and distributed enterprise 
applications (see enterprise hub at Figure 1).  
Some of the applications interface with the hub via 
client/server over ASU’s network backbone. 
Independent systems interface with the hub via 
program bridges between the two applications. 
(FIGURE NOT AVAILABLE IN ASCII TEXT VERSION).

The advantages of the EDI are many.  As ASU 
implements more and more client/server 
applications, EDI serves as a seamless data 
foundation, containing the enterprise data needed 
by distributed applications.  Tremendous economies 
flow to ASU by managing enterprise data through a 
single model and updating these data in a single 
database.  Distributed systems benefit by having 
the most recent occurrence of data, and information 
engineers benefit by having enterprise formats and 
standards to guide their work. Through EDI, ASU is 
banking on improved data integrity, lower costs in 
updating enterprise data, less data redundancy, and 
improved services to customers (see benefits listed 
below at Table 2). 

Benefits of Enterprise Data Infrustructure

  * One-stop update
  * Data foundation
  * Contributes to data integration
  * Ensures data integrity
  * Distributed developers know enterprise formats 
    and standards 


PIECES OF ASU'S ENTERPRISE DATA PUZZLE

Advocates of data administration maintain that 
enterprise data need high-level or corporate 
management.  However, ASU found that defining 
enterprise data is problematic because almost every 
data element is “enterprise” to someone or 
something!  In creating ASU’s EDI paradigm, data 
administration and the information technology 
departments conceptualized not only the data but 
what the data were about.  For example, improving 
customer service is a major goal at ASU; therefore, 
much of ASU's enterprise data concerns customers. 

Following this logic, ASU identified four major 
subject areas ("puzzle pieces") to EDI: (1) persons 
or organizations that do business with ASU, (2) 
work units or departments that comprise the 
organizational structure, (3) facilities used by 
both ASU's customers and work units, and (4) 
programs (academic, research, public service, etc.) 
that impact ASU's customers (see EDI subject areas 
at Figure 2).  These four high-level subject areas 
are the foundation of ASU's enterprise data 
infrastructure.  ASU re-designated the customer 
subject area as the "affiliate" after defining 
customers more broadly, e.g. students, employees, 
vendors, donors, constituents, etc.  Affiliates are 
anyone with a business relationship (affiliation) 
with ASU. (FIGURE NOT AVAILABLE IN SCII TEXT 
VERSION).

ASU's vision is that through a single model and 
database, ASU enforces the business rules for the 
data in each subject area.  For example, if an 
affiliate updates their address, the business rules 
for address are enforced by the affiliate data 
model and the update is stored in one location.  
Distributed or mainframe databases may replicate 
the address in affiliate, but the update occurs 
once.

ASU decided that the first EDI subject area built 
should be the area impacting the organization the 
most.  The data administration and information 
technology departments agreed that the subject area 
with the most pervasive impact concerns affiliates.  
This decision was made in part because of ASU's 
student information re-engineering project.  ASU 
wants to maximize the number of new client/server 
applications and plans to establish the interface 
with the Affiliate Data Model from the beginning 
for these applications.  Also, ASU's business units 
plan on implementing a "single" campus card for all 
business transactions.  The single campus card 
requires affiliate data services, such as a single 
affiliate ID for both students and employees.  By 
implementing the Affiliate, the campus card 
initiative has the ability to interface more 
broadly with other applications at ASU.


THE AFFILIATE MANAGEMENT SYSTEM AND ITS 
IMPLEMENTATION

The Affiliate Problem

Arizona State University has many business 
relationships with persons and organizations.  
Capturing information about the affiliations these 
persons and organizations have with ASU is an 
important factor in developing new and improved 
services.  In many cases, ASU affiliates have 
multiple relationships with the organization which 
are not understood.  

In the past, ASU's business practices and computing 
systems processed information about affiliates 
based on the needs of the department and not the 
needs of the enterprise.  Information about 
affiliate characteristics such as address, name, 
ethnicity, etc., is captured and stored in 
different formats using different definitions.  
When the same data are carried on multiple 
databases, the data are frequently out of sync with 
no way to know which occurrence of the data are 
correct.  As client/server technology advances, it 
is likely that the resulting distributed databases 
and applications will make this problem worse, 
unless enterprise data models and policies are 
implemented.

The end result is reduced levels of service, more 
expensive systems maintenance, a loss of data 
integrity, and redundant storage of the same or 
similar data.  However, the most strategic loss is 
the failure to fully understand the myriad of 
relationships that a single affiliate may have with 
the organization.  Understanding such relationships 
could result in a totally new view of ASU and how 
it serves its customers.  ASU hopes another big 
benefit will be significantly reduced computing and 
information costs.

The Affiliate Solution

The Affiliate Management System is an enterprise 
application and data model which solves these 
problems by defining and capturing in a single data 
base the attributes and relationships of affiliates 
that are important to more than one ASU 
departments.  Since affiliate data is stored in a 
single data base, in a single format, and based on 
a single definition, the data are more easily 
managed for the benefit of the organization.  When 
affiliate data are updated, all distributed 
applications interfacing with the Affiliate System 
immediately have the benefit of the new 
information. 

The Affiliate System has the advantages common to 
all EDI subject areas, i.e., reduced maintenance, 
update and storage costs, and increased data 
integrity and integratability (review benefits at 
Table 2 above).  However, Affiliate brings unique 
benefits by providing ASU a single customer ID that 
can be linked to other IDs, giving an ASU affiliate 
the capability of maintaining their "personal" 
data, making it less complicated for ASU to build 
applications to support sophisticated customer 
services (e.g., single-campus ID card) or affiliate 
to affiliate relationships (e.g., advisor/advisee), 
and making it easier for ASU to strategically 
comprehend the full extent of the relationships 
it's customers have with the organization (see 
unique affiliate benefits at Table 3).

Benefits of Affiliate Management System

  * Single ID (could be linked to other lds)
  * One stop update to personal info
  * Supports sophisticated services (i.e. mailings,
    e-mail, fax, etc.)
  * Ability to study affiliate relationships with   
    ASU
  * Supports affiliate relations with each other

The Affiliate Model

The high-level Affiliate Data Model contains nine 
entities (see model at Figure 3).  The most 
important entity in the model is the Affiliate.  To 
be an affiliate, a person or organization must have 
a name and a location (a way for ASU to communicate 
with the affiliate, i.e., address, phone, or e-
mail, etc.).  Affiliates are randomly assigned a 
unique ID which is a permanent identification 
number.  Business units decide when to create an 
affiliate record.  For example, the student 
recruiting office could decide to create an 
affiliate record for prospective students or wait 
until the "recruit" submits an application for 
admission. (FIGURE NOT AVAILABLE IN ASCII TEXT 
VERSION). 

In the Affiliate Model, there are two mandatory 
relationships between the affiliate and other 
entities.  One mandatory relationship is between 
the affiliate and an entity called "Affiliation".  
Affiliations are the "first-order" relationships 
affiliates have with ASU, e.g., student, employee, 
donor, vendor, etc.  Second-order relationships 
(relationships which are not mission critical, 
e.g., a dorm student) are not included in the 
Model.  ASU's data administration and information 
technology managers believe relationships which 
exist because of previous relationships are best 
captured in departmental applications.

A second mandatory relationship exists between the 
Affiliate entity and Address.  In order to become 
an affiliate, a person or organization must have a 
way of being contacted by ASU.  This may be a 
mailing, phone call, or e-mail message, but the 
organization must have a way of communicating with 
the affiliate.  This information is captured in the 
Address entity, where an affiliate can have 
multiple addresses, phone numbers, and e-mail 
locations with differing formats and differing 
uses.

Alias (other affiliate names), Demographics 
(ethnicity, birth day, gender, etc.), and Other IDs 
are entities which may or may not exist for an 
affiliate.  These contain data which describe or 
identify the affiliate to ASU.  The entity 
"Contact" contains information about persons who 
represent the affiliate.  For example, a 
corporation may have multiple contacts that 
represent the organization with ASU.  In this 
capacity, these persons are not directly affiliated 
with ASU, except through their relationship with 
the affiliate.  This is also true of a student's 
emergency contact.  The Contact entity contains the 
contact's name, address and phone number, and 
nature of the contact's relationship with the 
affiliate.

Affiliate to Affiliate relationships is an entity 
which provides for non-mandatory relationships 
between affiliates, some of which may be important 
for ASU to capture.  For example, if a group of 
donors are related in some way, that relationship 
may be strategically important for ASU to capture.  
More probable examples are faculty with similar 
research interests, or advisor/advisee 
relationships.  By capturing this information in 
the Affiliate Model, it is easier for ASU to build 
distributed applications which support the business 
needs that emerge from these relationships.  

Only one entity in the Model is related to an 
entity other than Affiliate: Institution.  At ASU, 
there are three campuses (Main, East and West) 
which comprise ASU as an Institution.  Affiliates 
can be affiliated with one or more campus, but this 
relationship only has meaning when the nature of 
the affiliation is known.  This relationship is 
mandatory so that it is clear what relationship an 
affiliate has and where (i.e., campus) that 
relationship exists.

Creating the Affiliate Management System meant that 
ASU developed new business rules to govern the 
Model and the data captured by the System.  These 
rules (see list at Appendix A) are still in the 
process of developing, but do indicate a 
significant shift in ASU's computing culture. 

Data Trustee Program

Building the Affiliate Management Systems resulted 
in many data issues which are not completely 
resolved (see list of issues at Appendix B).  ASU 
is creating a data trustee program to manage 
enterprise data and resolve the data issues posed 
by client/server. This policy states that a data 
trustee is assigned to each enterprise data element 
in the Affiliate Model.  The data trustee is 
responsible for managing these data according to 
University data policies, including facilitating 
access and insuring data security.  This program is 
administered by the Data Administration Office.  
Data Administration selects the data trustee, 
coordinates communication between data trustees, 
and facilitates all activities related to managing 
Affiliate data.  Data Administration is the 
ultimate authority over the use and management of 
all enterprise data at ASU.


DEVELOPING THE AFFILIATE MANAGEMENT SYSTEM

Phase One (March to June 1994)

The initial development phase occurred as part of a 
three month pilot project.  The purpose of the 
pilot was to test a new development methodology 
(Information Engineering), a new development tool 
(Composer by Texas Instruments), and a new 
computing environment (client/server).  The pilot 
consisted of developing the Affiliate Model and an 
application that processed a specific type of 
affiliate called constituents.  During this phase, 
an overall affiliate model was developed but 
detailed implementation only included those pieces 
of the model that were needed for the constituent 
application.  Business analysts from human 
resources, the registrar's office, institutional 
research, and data administration participated in 
the project as well as information technology 
analysts.

Second Phase (November 1994 to January 1995)

The second development phase included a larger and 
more diverse group of business analysts with 
representatives from admissions, financial aid, the 
graduate college, the registrar's office, sponsored 
projects, data administration, and the law college.  
Their charter was to review the "pilot" Affiliate 
Model, business rules, entities, and attributes and 
make any modifications needed to implement the 
model.

Third Phase (May 1995 to May 1996)

The third development phase is to implement the 
model validated in phase two.  This involves 
completing all entity and attribute definitions, 
and building windows to maintain what was 
determined to be "core" affiliate information.  The 
idea is to create a generic application to add and 
maintain affiliate information, knowing that 
additional windows will be needed later to enter 
affiliate information pertinent to a specific 
affiliation type.

CONCLUSION

     ASU believes that building an EDI is essential 
if client/server is to produce the benefits 
promised by industry.  The technologists will 
eventually solve all of the implementation problems 
of client/server.  Interfaces will be smooth and 
system performance not a problem.  What will be a 
problem is the loss of data integrity and ability 
to integrate data strategically as distributed 
applications capture and store enterprise data 
based on departmental definitions and standards.  
In building the Affiliate Management System, ASU is 
hoping to avoid this problem for critical segments 
of its business.  At this point, the jury is still 
out on whether this approach will work.  But be 
sure to stay tuned for future announcements!


APPENDIX A

Affiliate Business Rules

1.  Who is an affiliate?
An affiliate is a person or organization doing 
business with ASU
2.  What entities and attributes of objects belong 
in the Affiliate Data Model?
Entities and attributes of objects belong in the 
affiliate data model if they are enterprise, common 
to more than one "business process", and a 
"characteristic of an affiliate".
3.  What is required information to create an 
affiliate record?
To create an affiliate record, an affiliate must be 
separately identifiable, and have a means to be 
contacted.
4.  What are valid affiliation types?
Affiliation types are fundamental business 
relationships with ASU that are not concurrently 
dependent on other relationships.  Examples of 
affiliation types are student, constituent, vendor, 
employee, and donor.
5.  How will ASU format address?
Affiliate addresses conform to the U.S. Postal 
Service's format.  The affiliate address structure 
is extremely complex.  It allows for multiple 
address types and multiple addresses for each type.  
It provides the capability to designate an address 
as confidential or to be used for a specific 
purpose, such as mailing grades.
6.  What data is excluded from the Affiliate Model?
Highly sensitive relationships are excluded from 
the affiliate model to insure the privacy of those 
relationships.  Examples are HIV status, 
disability, etc.

APPENDIX B

Ongoing Affiliate Data Issues

ASU's data administration function and data trustee 
policies play an integral role in the new 
client/server environment.  These functions and 
policies are evolving and represent a cultural 
shift in how ASU's computing community views 
enterprise data.
ASU needs new policies and protocols to insure fair 
information practices.  Since the integration 
capabilities of the Affiliate Management System 
make enterprise data more powerful, it is paramount 
that employees understand the appropriate and 
ethical uses of the new capabilities.
In order to successfully implement the affiliate 
concept, business units need to agree on data 
definitions and usage.  The user community must 
abandon the "ownership of data" mentality that 
characterized past development practices.
ASU needs a way to secure certain sensitive or 
private data in the affiliate database.  Due to the 
nature of the information or the position of the 
affiliate, some data should not be accessible by 
the campus community.  The client/server 
environment opens a new set of security issues that 
were partially resolved in the mainframe world and 
need resolving in the client/server world.
ASU has several large purchased applications that 
need to interface with the Affiliate Management 
System.  These applications carry name and address 
information about employees and vendors that must 
be incorporated into the Affiliate Database.  ASU 
has yet to build the bridges linking these 
applications with the Affiliate, but is considering 
data replication.
Affiliate information needs to be updated by 
programs created with different application 
development tools.  ASU needs to maintain the 
integrity of the data by enforcing business rules 
about how data is updated.  This becomes more 
difficult when multiple application development 
tools are involved.  The client/server industry 
needs to address this problem.



Client/Server Grinch 11