Departmental Client/Server Application Development - Educause

This paper was presented at CUMREC '97, The College and University Information Services Conference. It is the intellectual property of the author(s). Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and that the title and authors of the paper appear on the copies. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the authors.

BACK

Applications and Consulting Information Technology Arizona State University A Recipe for Success: Departmental Client/Server Application Development Roger A. Lurie Application Systems Analyst, Principal Arizona State University Box 870101 Tempe, Arizona 85287-0101 [email protected]

Arizona State University Tempe, Arizona

The demand for administrative database applications always seems to exceed the resources available for development. As such, university departments are constantly on the look out for creative, innovative approaches to developing new systems that serve critical business functions. At Arizona State University, a number of projects have been successfully deployed in recent years using client/server technology. The projects identified here have taken advantage of PowerBuilder and Sybase technology. Key ingredients contributing to the success of these projects include: •

Collaborative development, involving human resources from the departmental units and Information Technology.

•

Integration of data from our university Data Warehouse with the departmental applications

•

Active participation by users, management and technical staff throughout the application development process.

•

Definition of a project scope that provides for fast delivery of usable business components.

During this session, we will explore the methodology used for development of these applications and review some case studies of successful projects that have been undertaken at ASU. Furthermore, one of the departmental applications developed using this approach that is now successfully deployed will be demonstrated during this session.

Applications and Consulting Information Technology Arizona State University A Recipe for Success: Departmental Client/Server Application Development Introduction and Background Arizona State University (ASU) is a leading national and international research and teaching institution. It is located in the Phoenix metropolitan area, with a total population of nearly 2.5 million persons. ASU is a rapidly growing multi-campus institution with a current enrollment of approximately 45,000 full-time and part-time undergraduate and graduate students. ASU offers a full range of degree programs from baccalaureate through doctorate. ASU is part of a three-university system governed by the Arizona Board of Regents (ABOR), a body corporate and politic with perpetual succession under the constitution and laws of Arizona. The regents select and appoint the president of the university, who is the liaison between the ABOR and the institution. The Applications and Consulting Information Technology (ACIT) department within Information Technology (IT) provides information resources for the administrative operating departments of the ASU campuses. The existing portfolio of ACIT managed applications are written primarily in COBOL, using the IDMS database environment. ASU also has applications in the DB2/CICS environment. These mainframe applications operate on an IBM 390 platform running MVS/ESA. An aggressive project is currently in progress to provide millennium changes necessary to keep these systems operational. To accommodate decision support and ad hoc queries, an ASU Data Warehouse has been developed using Sybase System 10, running on a SUN 630-MP server. A variety of graphical tools are used by Data Warehouse users for generating reports, with BrioQuery and Microsoft Access being the preferred products of choice. In the past four (4) years since the inception of the Data Warehouse, over 400 university faculty and staff have been trained. Demand for additional training exceeds available resources. An extensive project was initiated approximately four years ago to re-engineer business processes related to students services. This project, Student Process Re-Engineering Project (SPRP) has involved staff from ACIT, the Provosts office and a variety of administrative and academic offices. Several projects have been identified and are in progress to improve student related processes, including the information systems that directly impact these processes. Texas Instrument’s Information Engineering Facility (IEF) has been identified as the development environment for SPRP related projects. Concurrent with the efforts of SPRP, several departmental units have hired programmer/analysts and students to develop and maintain in-house applications. These departmental applications have focused primarily on the use of PowerBuilder, Sybase System 10 and S-Designor for technical implementation. While the central ACIT organization concentrates on maintaining existing legacy systems, conversion of programs to support millennium requirements and support for SPRP efforts, departmental needs are being addressed in a distributed, departmental paradigm. “Although the IS organization has traditionally been the default delivery point for IT services, that role is no longer guaranteed”, according to a GartnerGroup report, dated September 11, 1996. To further substantiate this approach, in a GartnerGroup report dated November 21, 1995, they state that “Today IS represents about 40 percent of IT expenditures. By 2000, IS,

2

with no changes in IS or enterprise behavior, will shrink to 22 percent of IT expenditures (IS remains constant, IT grows). We do not believe that IS will ever again (nor necessarily should) be the enterprise IT spending leader. However, we do believe IS must take proactive actions to increase its influence to maximize enterprise IT leverage.” In the College of Liberal Arts and Sciences (CLAS) at ASU, a Computing Manager (Kurt Johnson) has recently been brought on board, along with six FTE positions and $50,000 in student worker support for the support of technology within decentralized academic departments. Kurt states that the academic departments act autonomously in their use of technology, including development of business applications. Additionally, CLAS envisions a growing need for computing resources and staffing within the college. The Residential Life department within Student Affairs has recently geared up their computing support to include a Project Leader, 2 programmer/analysts and student workers. This unit is charged with maintaining existing computer systems, developing new client/server applications and supporting the decentralized residence halls on campus. The Graduate College is currently in the process of hiring a full-time programmer/analyst. The college envisions being on the leading edge of technology and developing more applications to provide better customer service to students, faculty and staff. ACIT has made a concerted effort to provide consulting resources to guide the departmental application development process. The result has been a successful recipe, with a mix of skills from information technology professionals, business users and departmental technical staff to bring forth new, innovative solutions. This paper will address the approach taken and explore some of the successful collaborative projects undertaken.

Ingredients to Success Methodology There is a enigma surrounding the use of this word in the context of application development. As defined in Webster’s dictionary, a methodology is “the science of method, or orderly arrangement”. Furthermore, we can break this definition down by looking at the meaning of method, which is “a way of doing anything”. Thus, a methodology is simply an orderly way of accomplishing work. Whether we recognize it or not, many things that we do in our lives from day to day follow an orderly pattern or methodology. This includes the method that we drive to work in the morning, where and when we go to lunch and how we spend our work time organizing tasks to be accomplished. There are several components to the methodology that have been applied for successful development and deployment of client/server projects at Arizona State University. These components are described in the following table:

Methodology Component Definition

Planning

Description Project Description Project Scope Project Resource Requirements Estimated Duration Establish Tasks Set Milestones Assign Resources Track Progress

3

Comments Prepare project definition document and obtain management support and sponsorship before proceeding. Prepare Project Plan and review with project team members and management

Design

Build

Implement

Evaluate

Joint Application Design (JAD) Business Process Modeling Data Modeling Prototyping Code Document Test Installation Configuration Management Training Post Implementation Review Product Enhancements Performance Tuning

Requires commitment of all project team members and business users.

Iterative process, bringing JAD session participants back together periodically. A real headache in client/server. Have users train users. Refine methodology for the next project.

It is important to recognize that the methodology described in this article is based on a foundation of guidelines. Rigid standards are inappropriate for a methodology used to develop client/server applications involving new technology and a collaborative team effort, where project teams are comprised of technical staff from IT and departmental units. In many scenarios involving departmental application development efforts, the project is managed by professional information technology staff employed within the departmental unit. Under these circumstances, a centralized Information Technology department is not in a position to impose rigid standards on an autonomous business unit. However, these departments are typically eager to participate if approached by an Information Technology department that can offer proven methods and guidelines for approaching their project. Guidelines promote the notion that every project will be unique and will require parties involved to be flexible. In the October, 1996 issue of Application Development Trends, Jane Griffin writes “In truth, many companies have been unsuccessful simply because the rigor imposed by the toolset does not allow for the kinds of problems that they encounter in the normal course of a project, for example changing requirements”. This methodology is not applied in a linear, sequential manner. The Project Definition and Planning should always be accomplished prior to initiating design and construction stages. The process of designing, building, implementing and evaluating should be an iterative process. This iterative process will provide the flexibility for processes to be further defined and clarified as the project progresses. Prototypes will provide users with a visual assurance that the design will meet business requirements. Business users of a system will typically identify additional needs once they are able to view screens or windows and test drive the application. This iterative process provides a means for identifying components of applications that may be delivered in a relatively short time frame. By delivering application components in a 3 - 6 month time frame, user satisfaction is increased, while minimizing apathy and a perception of project failure, which seems to be common in the development of client/server applications. In these projects, Information Technology consultants strive to define a clear and agreed upon scope for the project. Combined with the definition of relatively small components delivered in a short time span, frequently changing scope (commonly known as “scope creep”) is circumvented in these projects. The flexible approach provides some room for change and margin for error; however, the magnitude of these changes must always be assessed relative to the risk of delaying deployment. In many situations, these changing requirements can be accommodated in a future project phase. In the methodology applied at Arizona State University, business users are viewed as an integral part of the project. By extending this involvement to all aspects of the project life cycle, users take ownership and a personal interest in the successful completion of the project. As an example, an employee in the Graduate College perceived a direct threat to her employment by the project being developed to track

4

student recruitment. By involving her in day-to-day project meetings and asking for her feedback, this individual began to view the project as her own and adopted a positive attitude towards the project success.

Joint Application Development (JAD) One key ingredient to our recipe and methodology has been the use of Joint Application Design (JAD) techniques. JAD is a technique for designing detailed system requirements based on a consensus understanding of the business requirements. The JAD approach was initially developed by IBM in the 1970’s as a formal approach to facilitating combined sessions involved technical staff and business users. While there are a number of formal materials addressing the precise techniques associated with conducting JAD sessions, the success at ASU is largely based on an informal implementation. A room is specifically allocated in the Computing Commons building at Arizona State University for conducting JAD sessions. This room is equipped with a Panasonic electronic print board, easels, white boards and a layout of tables and chairs conducive to facilitated sessions with groups of up to 20 users. JAD sessions typically last for an extended duration of up to 4 hours, so comfort and a casual approach combined with focus on results keeps the process moving. Participants are free to get up and roam around the room or get a cup of coffee. All users are expected to attend every session and actively participate without concern for organizational hierarchy. The JAD sessions are conducted by Information Technology staff, which is a consulting service that is highly valued by the user community. Even departmental IS professionals that are somewhat skeptical at first, come around to see the value of conducting thorough analysis and design sessions. Russ Mohn, Research Systems Analyst Senior for the Office of Vice Provost for Research at ASU has stated that “the value of JAD sessions is getting the developers and users together to set common expectations and getting the users actively involved so that they feel ownership of the system”. As a facilitator of these sessions, it is often times interesting to look at the expressions of business users when they find that two people working side by side, day by day, are surprised by the work process steps executed by their own peers. By delving deeply, good JAD sessions are able to get real scoop about business processes and usually can uncover inefficiencies that can be improved. When developing a new business system, JAD sessions concentrate on identifying the following:

Identify Input

JAD Question • What creates or triggers a unit of work?

Process

• •

Output

•

What happens to the work after it is collected? What information needs to be collected to process the work? What results from the unit of work?

Example (Prospect Tracking) • Prospect calls ASU • Prospect sends email to ASU • Prospect is sent by an external data source, such as GRE • Mailings to prospect • Notify academic departments • Follow up by recruiters • •

Management information Assessing effectiveness of recruiting efforts

During the course of identifying input, process and output, always be on the look out for business processes that may be improved. Business process improvements, even in the most simplistic form can

5

significantly improve the way that work is accomplished, improve job satisfaction and result in higher customer satisfaction. During a JAD session to analyze and design a new Facilities Work Order Tracking system for the Residential Life department, a discussion arose concerning duplicate key requests. The process was smooth for occupants in the residence halls; however fraternity and sorority members were required to follow an 11 step process, involving two or three trips across campus and delays of up to 2 weeks to get their key. This process resulted in such frustration on behalf of the fraternity and sorority members, that they generally took matters in their own hands to duplicate keys and replace door locks. Obviously, this is a clear example of a situation where the business process could be improved. During JAD sessions, valuable information is being collected that helps develop a clear understanding by technical staff and business users of the application requirements. The sequence of identifying input, process and output translates well into a Business Process Model, which is input into S-Designor Process Analyst. This tool also provides a vehicle for identifying information flow required for the processing of work, that will carry over into the Data Model. Once the JAD sessions have thoroughly identified all processes and participants with the model, a Data Model is constructed. The data elements input into S-Designor Process Analyst carry forward to the Data Architect product and work begins on constructing a logical representation of the data, with all effort taken to avoid discussion of indexes, foreign keys and other database specific attributes. Typically, the technical staff from Information Technology and the departmental unit work collaboratively on this Data Model. Then, it is brought back to the larger group and business users are involved in understanding and refining and validating the model. Once this has been accomplished, the data model is transformed to a physical model and a test database is created. With a data model and a clear understanding of desired business processes in hand, JAD sessions are conducted to design the application windows and batch processes. The PowerBuilder tool set has valuable components that are helpful in prototyping, such as the DataWindow, which is a graphically designed SQL painter. We often find that the optimal windows to benefit business users are ones that are flexible and potentially involve multiple tables. Also, search windows and menus are best thought out on paper. Therefore, these JAD sessions usually produce a paper layout of the windows. At a later stage, the actual PowerBuilder prototype is built and reviewed with the group for refinement.

Data Warehouse A highly successful Data Warehouse has been implemented at Arizona State University. Since the inception of the project led by John Rome, Assistant Data Administrator, several mainframe application components have been integrated into this subject oriented data warehouse, including student, financial, human resources and financial assistance data. The information has been modeled and effectively organized for easy understanding by users. Commonly used elements are grouped together and data transformation is done to provide quick, meaningful results to novice users. The ASU Data Warehouse is refreshed periodically using batch programs that extract data from IDMS, DB2 and VSAM files and load into Sybase relational tables. The frequency of extracts varies with some components such as name, address and lookup tables are updated daily. Other components are updated weekly, such as student courses and grades, while snapshot data is maintained for longitudinal reporting. With some degree of controversy, departmental applications are tapping directly into the Data Warehouse to fulfill needed data requirements. From the departmental perspective , this endeavor has been quite successful and has allowed the deployment of applications, without redundant duplication of data. With limited Information Technology staff to provide methods for extracting data to send directly to a department, the Data Warehouse has been viewed as a viable method of obtaining required data. “Until people can access legacy systems easier, the warehouse will fill a lot of the universities data gaps”, states John Rome, ASU’s Assistant Data Administrator. In some scenarios, these departmental applications are

6

using lookup tables, while in other applications, name, address and additional demographic data is obtained directly from the Data Warehouse using logical views.

Collaborative Effort Another successful ingredient to our recipe for departmental application development has been a collaborative effort involving technical staff and business users from the units mixed with technical consultants from Information Technology. According to the GartnerGroup, “New applications increasingly will be distributed, cooperative and collaborative with heavy and direct user involvement in creation and use”. In some scenarios, the Information Technology staff at ASU have participated in the development of the application, while in other cases, the role is limited to consulting services. Kent Blaylock, Director of Administrative Services and Information Technology at the ASU Graduate College states that “the collaborative process, involving staff from the business unit and IT was very successful. The JAD sessions helped us take a closer look at the way we were doing work in the past and finding ways to improve processes.” Consulting services are provided to any academic or administrative unit at ASU in an effort to develop effectively designed systems, with an agreement outlining departmental and ACIT responsibilities. The consulting services are also provided internally, to intra-Information Technology units. These services include: Strategic Planning Joint Application Development (JAD) Facilitation Hiring/Staffing Assistance RFP Development and Response Evaluation Project Scope Definition Project Management Process and Data Modeling Database Design Application Design System Interfaces Design Graphical User Interface Design PowerBuilder Development and Implementation Techniques Web Development and Implementation Techniques Application Development Guidelines These consulting services lead to effectively designed applications and a high degree of satisfaction amongst the business users. Departmental technical staff are often eager to work with the IT consultants and participate, provided that it is viewed as a collaborative effort. In addition to consulting services, ASU offers centralized management of relational database servers for departmental use. This service is viewed attractively by the departmental staff. In some circumstances, departments have attempted to manage their own Sybase server only to realize the tremendous effort and expertise required. Furthermore, consistent backups are maintained from these servers, providing a comfort level to departments with their own mission critical application.

The Tools The tools are viewed as a successful ingredient to our recipe at Arizona State University. The tools, however, are a secondary contributor to the success of these projects relative to the value of people, perceptions and approach.

7

PowerBuilder PowerBuilder has been selected as the appropriate application development environment for several of our successful projects. It is an object oriented, graphical, 4th generation language with a reasonable length learning curve. There are aspects of the PowerBuilder toolset that lend themselves to quick start by the novice developer, while other components are more sophisticated and require considerable effort for familiarity and productivity. With PowerBuilder being actively taught in academic curriculum at ASU, departments have often tapped into the classroom to hire student workers and graduate assistants that already have some experience with the product. PowerBuilder is also viewed as a more accessible and affordable product than some of the integrated CASE tools for developing mission critical applications at the department level. The latest release, PowerBuilder 5.0 offers functionality that enhances the products viability for mission critical application development, including three tier architecture, version control, Intranet development components, cross platform capabilities and compilation to machine code. S-Designor S-Designor has been identified as the process and data modeling tool of choice. It is a product that is intuitive and relatively easy to learn, providing an incentive for departmental staff to take the time to develop models of their business. The Information Engineering (IE) methodology is supported and a central repository is offered for management and version control of models. The S-Designor 5.0 product offers a feature enabling the developer to create a rapid prototype of an application for PowerBuilder or Visual Basic. Microsoft Access Microsoft Access has been used by a number of departmental units at Arizona State University for development and deployment of workgroup and personal level applications. Microsoft Access is also frequently used by Data Warehouse users for reporting and integration of data from heterogeneous data sources, such as Sybase and Microsoft Access. Brio Query Brio Query is the supported tool of choice for reporting from the ASU Data Warehouse and other departmental Sybase databases. It is an intuitive, fast and simple to use report writer, allowing the novice to come up to speed very quickly.

8

Successful Projects The following table identifies successful projects undertaken at Arizona State University using the recipe ingredients identified in this article.

Project ASU Foundation Reporting

Data Warehouse Components Alumni/Foundation data

Information Technology Staffing 1 FTE

Departmental Staffing .25 FTE

Class Roster Reporting

Student, Person, Course, Lookup

1 FTE

4 months

Disability Resources

Student, Person, Lookup

1 FTE

.5 FTE (Committee) .5 FTE

Graduate College Prospects

Lookup

2.5 FTE

1 FTE

9 months

Property Control (*)

Financial

.25 FTE

2.5 FTE

12 months

Research Proposal and Awards

None

.1 FTE

2.5 FTE

24 months

Residential Life Work Order

Residential Life, Student, Person

1.5 FTE

2 FTE

6 months

(*) Denotes projects that are in development at the present time.

9

Project Duration 3 months

3 months

Recipe Pitfalls No recipe is without pitfalls or issues, including the one described in this article. The items to watch out for in this recipe are as follows: University Perspective Departmental application development can potentially be self serving and ignore the overall objectives and goals for the university. Some of this perspective stems from thinking that university business systems should all be developed and managed by the central ACIT organization. These departmental projects are often driven by a limited scope and set of objectives. Information Technology consultants are often in an excellent position to mediate in this effort. At ASU, we make every effort to foster a university perspective by the department controlling the application development process, or at least, to look outside of their own department and involve other business users that may be effected. For example, a business system need has been identified by both the Graduate College and Financial Assistance for scholarship processing and tracking systems. Prior to proceeding with disparate projects, an effort will be made to conduct JAD sessions involving both departments to determine if the business processes are similar enough to pursue one collaborative project for the benefit of the university. Departmental costs There are a number of costs associated with departmental computing and development of decentralized applications. Often times these costs, particularly related to staffing are overlooked by the department as they prepare to develop business applications. GartnerGroup, in a report dated September 11, 1996, states that “many business units are opting for bottom-up implementations, ignoring (or ignorant of) the labor components or burden on IS resources, as end-user computing is being transformed into enterprise-wide distributed computing. Bottom-up implementations use the installed base of personal productivity technology to support enterprise-level office automation, production systems and a myriad of client/server applications.” The consultants employed by the central IT department at ASU have made an effort to work closely with the departmental units in an effort to set realistic expectations regarding staffing and other departmental costs. Staff retention Using client/server technology, staff retention is an issue. Of course when employing student workers and graduate assistants, we anticipate an eventual graduation. However, departments are encouraged to employ full-time permanent staff to oversee projects and maintenance. The permanent staff is also a perpetual issue, where experienced client/server developers employed by departments find opportunity to work outside of the university at a substantial salary increase. Departments are encouraged to identify funds within their budget to offer attractive salaries that retain qualified, permanent technical staff. Stability of data warehouse The departmental applications are highly dependent on the ASU Data Warehouse. Typically, the warehouse is stable and dependable. However, there are instances where a batch load does not complete successfully or a hardware problem causes interruptions in service. Often times when problems occur, the data warehouse is not viewed as a mission critical resource. In these situations, departmental applications

10

may be unavailable. This problem has only created minor inconveniences to the departments at this point in time. Infrastructure priorities Infrastructure priorities are often driven by enterprise needs, not departmental needs. Thus, issues related to computer account management, backup and recovery, software distribution, UNIX batch scheduling, production printing, database performance tuning and enabling of gateways is viewed as being relatively low in priority when identified by departmental needs.

Putting it all Together With all of the ingredients for the recipe in mind, let’s put them all together. First, you must put your creative hat on. All good cooks have special techniques to ensure the success of their recipes. Start with a well greased organization, where work gets done and job morale is high and Information Technology staff are encouraged to pursue new creative solutions to old problems. On top of this well greased organization, roll the methodology out as a foundation for all of the other ingredients that will be placed on top. Brown the methodology ever so slightly in the oven, being careful that it does not get too hard, rigid or burned. The methodology should be well done and seasoned, taking care that it does not become overdone. With the methodology in place, you may now add a mixture of JAD techniques, a Data Warehouse and collaborative efforts of an energetic team together. Mix these together and spread out thoroughly over the methodology. Then, sprinkle the client/server tools on top. You are ready to indulge! Enjoy!

11

References Gartner Group, Inc. (September 11, 1996). [Inside Gartner Group This Week, Volume XII, No. 37. Distributed Computing: IS Organizations Must Adapt or Vanish] GartnerGroup, Inc. (November 21, 1995). [Research Note: Dispersed IS Organization Imperative] Griffin, Jane (October, 1996). Speeding Up RAD. Application Development Trends.

BACK

12