Administrative Information Services Imperative:

AIS Enterprise Systems Roadmap

Final Report

Authored by: Mike Belinc, AIS Enterprise Systems Architect

Date: 1/20/2005

Project Acknowledgments

Several people contributed to investigative effort that ultimately led to the recommendations brought forth in this imperative. Covering all the bases in an exploration of this magnitude is a monumental task and can be daunting. Nevertheless, without their invaluable input, the results could not have been achieved.

Primary participants:

Mike BelincBill CookBrian FranceBob O’Connor

Secondary participants (“Virtual Team”):

Carl Seybold Applications Development Ed Hayes Applications Development Peter DeVries Workflow Pete Dawson Mid-tier solutions and services Lowell Smith Distributed Systems Scott Neidigh Distributed Systems Scott Weaver Computer Operations Steve Strickler Production job scheduling Todd Litzinger Security Denny Morrison IBIS Dawn Boyer ISIS

2

Table of Contents:

Project Acknowledgments......................................................................................................................... 2

Glossary..................................................................................................................................................... 5

Executive Summary.................................................................................................................................. 6

Project Background.................................................................................................................................. 7

Project Objectives...................................................................................................................................... 8

Potential Outcomes................................................................................................................................... 8

Project Strategy—Delivering a Roadmap................................................................................................. 9

Conclusions............................................................................................................................................. 10

Appendix A: Research Results................................................................................................................ 11

Mainframes....................................................................................................................................................11

Operating Systems.........................................................................................................................................12

Databases........................................................................................................................................................12

Summary........................................................................................................................................................13

Appendix B: Additional Observations..................................................................................................... 14

Appendix C: Issues.................................................................................................................................. 15

Production Batch Jobs...................................................................................................................................15

Business Requirements..................................................................................................................................15

Historical Business Processes.........................................................................................................................15

Middleware.....................................................................................................................................................15

NATURAL Programs....................................................................................................................................16

Performance and Scaling Factors..................................................................................................................16

Enterprise Application Integration (EAI).....................................................................................................16

Training Requirements..................................................................................................................................16

Distributed Databases....................................................................................................................................16

ADABAS Data Access....................................................................................................................................17

Risk Assessment Based on Existing Investment in Mainframe Technology.................................................17

Security...........................................................................................................................................................17

Reliability and Stability.................................................................................................................................17

Database Functionality..................................................................................................................................17

Cultural Changes and Logistics.....................................................................................................................17

Vendor Issues.................................................................................................................................................18

Appendix D: Databases Cross-Referenced to Hardware (Part 1)...........................................................19

Appendix E: Databases Cross-Referenced to Hardware (Part 2)...........................................................20

Appendix F: Databases Cross-Referenced to Operating Systems (Part 1)..............................................21

3

Appendix G: Databases Cross-Referenced to Operating Systems (Part 2).............................................22

Appendix H: Hardware Cross-Referenced to Databases........................................................................23

Appendix I: Hardware Cross-Referenced to Operating Systems.............................................................24

Appendix J: Operating Systems Cross-Referenced to Databases (Part 1)..............................................25

Appendix K: Operating Systems Cross-Referenced to Databases (Part 2)..............................................26

Appendix L: Operating Systems Cross-Referenced to Hardware.......................................................27

4

Glossary

AIS – Administrative Information ServicesAIX – Advanced Interactive eXecutiveASET – Academic Services and Emerging TechnologiesBTOS – Burroughs Technologies Operating System COLD – Computer Output to Laser Disk CORBA – Common Object Request Broker Architecture EAI – Enterprise Application Integration (Imperative)HP – Hewlett-PackardIBM – International Business MachinesITS – Information Technology ServicesJ2EE – Java 2 platform, Enterprise EditionMCP – Master Control ProgramMS – Microsoft OS – Operating SystemSAG – Software AGSGI – Silicon Graphics IncorporatedSOAP – Simple Object Access Protocol SQL – Structured Query Language VM – Virtual MachineVMS – Virtual Memory System VOS – Virtual Operating SystemVSE – Virtual Storage Extended WWW – World Wide WebXML – eXtensible Markup Language

5

Executive Summary

When one takes an investigative look at hardware and software infrastructure it immediately becomes evident that it is a difficult task at best to undertake a full analysis of all of the possible combinations of hardware, operating systems and databases available in the computing industry today. However, an effort to corroborate the validity of an existing infrastructure may in fact require a minimal exploration of some of these combinations.

Our research quickly uncovered several key criteria that warrant more extensive investigation than the time line for this imperative would permit. Nonetheless, several decisive conclusions have been made with respect to “narrowing the playing field” of plausible directions to pursue. This report highlights a recommended approach to further the research required to determine a long-range strategy for migration to any new hardware platform, operating system and/or database infrastructure. Specific requirements will have to be defined, mapped to possible combinations of architectures and then weighted in terms of their level of importance and implementation viability.

We have documented some of the more plausible combinations of architectures encountered during this endeavor. Strategies that have been recommended in earlier imperatives are given due consideration. Still, it would require a giant “leap of faith” to make a determination based on the limited criteria used to gather information thus far. Our commitment to adopt J2EE programming standards for future application development along with our effort to control our mid-tier server growth rate are important decisions that will require the allocation of significant personnel resources—throughout all administrative computing departments—over the next few years. A steep learning curve will drive the need for a long training period for application developers, operations and systems personnel.

If we are ever to undergo a complete change in hardware and/or operating system software, our dependence on mainframe production batch procedures required to satisfy numerous business requirements presents a daunting challenge. While we did not spend time researching alternatives to these processes, it quickly becomes evident that a move to new platform and/or architecture could require some rather significant changes in existing business processes. This is a very important business decision that will need to be made before we consider migrating to a new administrative computing infrastructure.

Our conclusions indicate that our infrastructure direction over the next 3-5 years will be to “stay the course”, namely continue our efforts to develop new applications in Java, consolidate as many Intel servers as possible onto either zSeries with z/VM and zLinux or bigger Intel servers with VMWare and continue to upgrade our zSeries hardware and its z/OS operating system as well as our mainframe database environment. In addition to these already engaged efforts, we should start to look into consolidating down to a more manageable number of database systems in our distributed systems environment. If we follow the strategy recommended in the conclusions, we should narrow our exploration to a very select few hardware platforms, operating systems and/or databases and exercise a much more in depth analysis of the business requirements that might drive a final selection.

Based on our conclusions, the recommended next steps are as follows: Continue to move toward Java as our primary application programming language. Continue to move forward with our consolidation strategy for mid-tier servers, ensuring that we can in fact

exploit this new operating environment to our advantage. Move forward with the purchase of new zSeries hardware. Determine business requirements to be included as evaluation criteria for defining an infrastructure component

replacement strategy. Investigate the need to alter business requirements based on potential replacement of batch job procedures. Develop and implement a training strategy for moving forward. Investigate the consolidation of distributed system databases. Explore the viability of ADABAS and DB2 as our universal database architecture. Explore the viability of Unix as our universal operating system platform.

6

Project Background

In late 2001, Administrative Information Services began working on several strategic initiatives aimed at trying to assess the viability of some of its longest-standing technology platforms including: IBM mainframes and their MVS and OS390 operating systems; Software AG's ADABAS database, COM-PLETE transaction monitor and NATURAL programming language; and storage media. While a decision embracing IBM's Enterprise Storage Server technology as a long-term centralized storage solution was made during this process, time constraints limited decisions in the former areas to committing to a 5-year extension of contracts with IBM and SAG for their associated technologies. Now midway through the 5-year renewal cycle, we must revisit the confirmation of these two long-standing vendors' product sets and try to determine more succinctly whether or not they are still viable as long-term architectural strategies for the next 5-year cycle—and perhaps beyond.

Several factors play significant roles in rejoining this effort. Most significantly, both vendors have recently introduced new technology capabilities within their product lines. Meanwhile, AIS has made a strategic decision to embrace the Java programming language via IBM's WebSphere as its future development platform for Enterprise Application Integration. AIS has also committed to migrating production mid-tier server applications to IBM's zVM and zLinux operating systems utilizing mainframe Integrated Facility for Linux hardware. Independently, these latter two important strategic decisions should have no direct bearing on deciding which hardware platforms and/or database engines AIS should use in the future for Administrative computing. It will be important however to ensure that any analysis of this type consider the existing experience gained during the past 20+ years in our current environment as a significant factor in making any major changes in this architecture. On the other hand, if there is a better combination of hardware platforms, operating systems and/or database engines that will provide a more robust and flexible production and development environment for the future then this effort must provide a road map to get us there.

Assumptions:

(1) A centralized storage media has been selected and will therefore not be evaluated further by this imperative.

(2) Java will be portable to any hardware and operating system platform we happen to choose.

(3) Java will also be compatible with any database platform we might select.

(4) Should it ever become a beneficial direction for AIS to utilize non-zSeries platforms, zLinux applications will be portable to Linux operating systems running on other platforms.

(5) Over time, as we ramp up the Java programming environment, new applications will be developed only for the Java environment and dependence on NATURAL will steadily diminish.

(6) This imperative will not examine NATURAL or any other programming languages in relation to hardware, operating system or database support.

(7) Existing and future network transport functionality must be compatible with any platform(s) selected.

(8) Implementation of any new database, hardware or operating system environment selected will require a lengthy transition period. Existing operating system and database functions must be able to work side-by-side with any new operating system and database functions during the transition period.

(9) The Windows operating system will be with us for the foreseeable future. There are simply some vendors from whom we procure mid-tier server software who will only support this environment for now. As time goes on and perhaps the numbers of these types of applications dwindles, we may revisit the required functionality in an effort to migrate to the newly adopted operating system platform(s).

7

Project Objectives

The specific goals of this imperative are as follows:

(1) Reconfirm that the IBM zSeries is the most logical, primary platform for administrative computing in the next 5 years.(2) Reconfirm that the Software AG ADABAS database is the most logical, primary data repository for administrative computing in the next 5 years.(3) If a decision is made to move away from the IBM zSeries platform, provide a road map as input to a project to transition to the new hardware and operating system platform. (4) If a decision is made to move away from the Software AG ADABAS database platform, provide a road map as input to a project to transition to the new database platform.

Potential Outcomes

In any endeavor to recommend a new data processing environment we must first establish some weighted criteria. Regardless of other criteria selected for evaluation, we proclaim that vendor support must be very high on the list of priorities. This is even more important if we plan to migrate to a completely new infrastructure. On this basis alone, we can quickly pare down to a handful of combinations between hardware platforms, operating systems and databases. The following represents our final recommended selection options of these individual environments (reference Appendix A for corroborating data):

Operating Systems: Databases: Hardware Platforms:HP’s HP/UX IBM’s DB2 HP’s IntegrityIBM’s AIX Oracle HP’s 9000IBM’s zSeries Software AG’s ADABAS IBM’s pSeries(includes z/OS, z/VM and zLinux) IBM’s zSeriesSun’s Solaris Sun’s SunFire

Possible parings for the above options can be condensed into two workable scenarios. First, if we decide to continue to support the zSeries mainframe environment, then we conclude that the only viable options for database selections are IBM’s DB2 or Software AG’s ADABAS. This precludes selection of any non-zSeries operating system—at least for the mainframe—although we would still be able to consider HP’s HP/UX, IBM’s AIX or Sun’s Solaris operating systems at a mid-tier server level since DB2 and ADABAS are both supported in these environments (e.g. could be used to support an integrated data warehouse).

Second, if we decide to move away from a mainframe environment (remember, this implies that a business decision must be made re changing business requirements for batch processing on the mainframe), then we conclude that the only viable options for database selections are IBM’s DB2, Oracle or Software AG’s ADABAS. Meanwhile, HP’s HP/UX, IBM’s AIX or Sun’s Solaris operating systems would be viable selection options. Interestingly, in this scenario, IBM’s z/VM and zLinux would continue to be viable operating system selection options—based on software cost and scalability.

As for hardware platform selections, these can be derived after a selection has been made in the other two areas.

8

Project Strategy—Delivering a Roadmap

Moving forward, we need to establish a set of comprehensive evaluation criteria based on the findings found within this report. We need to assemble a team of AIS personnel who can determine the business requirements that should be included in the evaluation criteria. A key analysis that must be executed is to research the business requirements associated with our production batch jobs. Any migration away from the mainframe environment will need to find a replacement mechanism for these—either via new processes built into the new infrastructure environment or via actual replacement of the business processes with new business solutions (e.g. replacement of printed forms by electronic forms). The aforementioned business requirements analysis would provide a risk assessment of the existing investment in mainframe technology.

As we continue the AIS EAI initiative, we need to be cognizant of the development of new modularized coding techniques and the gradual replacement of our NATURAL programming environment. At some point along the path of this effort it will be appropriate to time the completion of any new infrastructure selection decision. This will coincide with less dependence on NATURAL and more reliance on Java, providing a more platform-independent architecture.

We need to continue to develop a training strategy that will allow us to progress through the various stages of our current initiatives. In addition, we need to start planning now for new training requirements that arise as we recommend any new infrastructure components.

Meanwhile, we must continue to pursue our implementation strategy recommended by the “Web-Based Infrastructure Strategy” initiative. In addition to VMWare consolidation efforts, we should at least explore AIX as an interim operating system in our efforts to consolidate Intel-based servers. (This is based on recent findings that indicate that we will not be able to migrate any of our Cincom VisualWave mid-tier server applications to zLinux). This would provide a beneficial opportunity to explore the AIX operating system as part of the follow-up analysis recommended by this imperative (to explore the validity of Unix as our universal operating system). In addition, the migration from AIX to zLinux (and Linux) is much easier than a migration from the Windows server environment to either AIX or zLinux. While we continue to make plans to move away from our existing middleware infrastructure, we can take advantage of existing AIX experience in the Academic Services and Emerging Technologies (ASET) group. Simply, we would rely on them to help train us to support this new environment. (Training is one of the recommended follow-up strategies). This would allow us to continue our Intel server consolidation efforts while we explore middleware solutions that will work on zLinux. While our goal is to eventually migrate to the zLinux environment, we can reduce our support requirements in the Windows server environment enough to free up resources to work on porting applications to both the interim AIX environment and the future zLinux environment.

As for investigating other hardware and/or software platforms as potential future replacements for our existing infrastructure, we recommend using IBM’s pSeries hardware running the AIX operating system as our testing environment to investigate the viability of Unix as a potential future administrative computing environment. (A more comprehensive evaluation of specific Unix hardware and operating system platforms can be undertaken if it is determined that Unix is a viable option).

On the database side, we recommend that IBM’s DB2 and Software AG’s ADABAS be evaluated as a potential single database engine utilized across both mainframe and distributed system platforms. This evaluation can be coordinated with the aforementioned evaluation of pSeries hardware and the AIX operating system. As we are already familiar with running ADABAS on the mainframe and DB2 on the distributed systems platforms, we would only need to evaluate ADABAS on the distributed systems platforms (i.e. AIX) and DB2 on the mainframe. This evaluation should include an assessment of the business requirements that would drive the decision to support relational database architecture vs. non-relational database architecture.

9

Conclusions

While we cannot make any specific recommendations at this time with respect to making any major change to our database, operating system or hardware infrastructure, we are able to indicate some areas for potential exploration. Regardless of what follows this imperative as a project—or set of projects—we explicitly recommend that any serious consideration given to explore the possibility of changing one of our major infrastructure components must be assigned dedicated resources. In addition, we recommend that an implementation team should be formed that will be comprised of personnel resources from multiple areas within the organization such that all of the areas discussed within a particular component selected for investigation can be represented in a complete evaluation. The scope of this effort should not be taken lightly. At the same time, there are several focus areas where we should invest some time and resources. Even though making a significant decision to change a major part of our infrastructure within the next five years would be a daunting task, our research nonetheless provides us with some valuable options for moving forward. Under this guise, we make the following recommendations:

Continue to move toward Java as our primary application programming language. Continue to move forward with our consolidation strategy for mid-tier servers, ensuring that we can in fact

exploit this new operating environment to our advantage. Determine business requirements to be included as evaluation criteria for defining an infrastructure component

replacement strategy. Investigate the need to alter business requirements based on potential replacement of batch job procedures. Develop and implement a training strategy for moving forward. Move forward with the purchase of new zSeries hardware. Investigate the consolidation of distributed system databases. Explore the viability of ADABAS and DB2 as our universal database architecture. Explore the viability of Unix as our universal operating system platform

Appendix A: Research Results

In order to reconfirm that our existing Enterprise Systems should continue to comprise our primary administrative

10

computing environment for the foreseeable future, we first need to understand what other Enterprise Systems environments are available as potential replacements. Having no set criteria or requirements beyond the generic capabilities to handle all of our business applications, there was no way to immediately limit the scope of such research. There are literally hundreds of operating systems, hardware platforms and databases available on the market today. However, there are some very succinct criteria that we were able to define once our research efforts got under way. The following areas describe some of the analysis we did and some of the more immediate conclusions we made in an effort to narrow the scope of our research.

Mainframes

Our research indicates that if we were only talking about changing our mainframes and keeping everything else status quo, then it would not be prudent or even cost-justified to move away from the IBM zSeries platform. Some corroborating evidence can be cited re the major mainframe manufacturers:

...Amdahl…Fujitsu has purchased Amdahl. While Fujitsu plans to continue to maintain and support the existing lines of Amdahl hardware, they have no future plans to develop beyond a 31-bit architecture. There main thrust seems to be in maintaining support of the existing Amdahl client-base. Therefore, based on our continually increasing use of mainframe cycles, we will arrive at a point where we will be required to move to a 64-bit architecture in order to support this growing demand on mainframe resources. Thus, Fujitsu would be ruled out as a viable mainframe alternative to IBM's zSeries—again, based purely on a one-for-one exchange of hardware platforms.

...Hitachi…Their AP and MP Series mainframes—geared toward e-Business solutions, especially in the financial industry—are limited to the domestic Japanese market only and are therefore automatically eliminated as potential replacements for our existing IBM zSeries platform. Hitachi also produced US-branded mainframes in 3 series: (1) Pilot, (2) Skyline and (3) Skyline Trinium. However, Hitachi is also no longer actively selling mid-range or high-end mainframes against IBM, although they continue to service their installed bases. Thus, Hitachi is also ruled out as an alternative to IBM zSeries—as indicated above.

...Unisys…Although they tout their new hardware as "mainframes", they are not of the "traditional variety". Instead, the Unisys "mainframes" support their own Unisys mainframe MCP operating system, on either mainframe processors or Intel Xeon processors. In addition, they support server modules running Microsoft Windows Server 2003 Enterprise and DataCenter Editions on Intel's Xeon processors or Itanium 2 processors. Clearly, Unisys mainframes would not be a viable mainframe alternative to IBM's zSeries—once again, given a one-for-one swap of hardware platforms. More simply put, z/OS will not run there!

...Other…All of the other mainframe platforms consist of some combination of non-zArchitecture-based medium and large processors and/or provide specialized functionality. All of these are also therefore ruled out as potential replacements for IBM's zSeries in any one-for-one hardware-only exchange. However, some of these other mainframe systems may well come back into focus if we consider a change in operating system platform. For instance, IBM’s pSeries, the Fujitsu PrimePower, HP AlphaServer, HP Integrity, HP9000, Bull NovaScale and Sun SunFire hardware platforms all support some form of Unix operating system and will scale up to mainframe capacities. The only "other" mainframe type researched that can be immediately eliminated would be SGI's line of processors—these are geared specifically for high-intensity graphics applications.

Operating Systems

Our research indicates that there are a number of different classifications of operating systems: (1) Linux, (2) Mac OS, (3) Windows, (4) Mainframe OS (5) Unix and (6) Other—including VMWare, IBM's OS/400, Novel

11

NetWare, OpenVMS, SASOS and Sun's JavaOS. While the research in the mainframe area panned out fairly quickly, the research in the operating system area required a more intense analysis. While there were many options to explore, only a handful should be considered to satisfy "supporting an Enterprise Infrastructure".

We can quickly rule out Mac OS and Windows desktop and server operating systems (perhaps with the possible exception of the Windows DataCenter operating system—more detail will be included later) as viable replacements for our existing enterprise z/OS operating system. In addition, those operating systems classified in the "Other" category can likely be ruled out as "Enterprise Solutions". These are included primarily for their potential value as "partner" operating system environments that may complement whatever selection(s) we make in this area (e.g. VMWare is being touted as a primary vehicle for server consolidation).

Hence, we have pretty much pared down our operating system choices to Linux, Unix and the Mainframe operating systems. Given that the non-IBM mainframe vendors no longer have plans to develop new architecture to compete with IBM's 64-bit zArchitecture, operating systems from these vendors can also be ruled out as potential replacements for the zArchitecture operating systems. These include Unisys (Burroughs) BTOS, Fujitsu (Amdahl) MSP and Hitachi VOS3/xS. Furthermore, replacing the current zArchitecture with any operating system that has no current install base within Penn State implies that we would need to develop a completely new operating systems and mainframe support team—without the assistance of any internal ITS or University experience.

Therefore, the only viable mainframe operating systems to pursue are IBM's z/OS, z/VM, zLinux and/or z/VSE. Of course, should we choose to change platforms in the future, Unix and/or some level of Linux would also be potential choices.

Since IBM's z/VSE is more of a mid-range hardware operating system, it will not likely scale to the level required of our current application development, database and batch environments. In this light, we will eliminate z/VSE as a viable alternative to our current mainframe operating system environment.

Databases

Again, the research showed that databases may be divided into several categories of types—as follows: (1) Data Warehouses, (2) Multi-dimensional, (3) Non-Relational, (4) Object-Oriented, (5) Relational and (6) XML databases. Curiously, Geographic Information Systems are also considered databases. However, they are very specific as to the types of information they hold and manage. Since these are not germane to our search for Enterprise-wide Administrative databases, we will thereby exclude them from our analysis.

A cursory look at the aforementioned database categories quickly yields a further breakdown. Data Warehouses were never intended to be Enterprise data stores for current (up to the millisecond) information. Rather, they are more used for longer-term data analysis. As such, we can eliminate all of the databases in this category in our search for an Enterprise-wide data repository—although it should be noted that any enterprise-wide administrative database selection should include data warehouse integration as one of its selection criteria. Similarly, multi-dimensional databases fall into the data analysis area. However, more research needs to be done to determine the long-term viability of these databases as an Enterprise-wide data repository and/or a complimentary integrated data store similar to data warehouse functionality.

Object-oriented databases seem to fall into a category all their own. They can be used to supplement an Enterprise database by breaking it into smaller "objects" that can in turn be used to more granularly quantify the Enterprise data repository—without needing to process all of the data housed there. (More research is needed!). XML databases may also fit into a similar "supplemental" category and although we are currently researching Software AG’s Tamino XML database as a supplement to ADABAS, we feel we can narrow our enterprise data repository search down to two final categories: Non-Relational and Relational.

As the data processing history of AIS (and its else-named predecessors) will attest, the primary data repository for Penn State's administrative data has always been held in a non-relational database. With more recent expansions of

12

support into the relational databases of Microsoft SQL, Oracle and IBM's DB2 in the distributed platform area, a more diverse database landscape has been forged. It is here that we must note the most recent time period of two decades has been highlighted exclusively—on the mainframe—by the migration (in the early 80s) from IBM's IMS non-relational database to the current Software AG's ADABAS non-relational database environment. (We will make an assertion here that ADABAS did indeed provide us with more functionality than its predecessor, and we may thereby eliminate IMS as a possible replacement for ADABAS).

While the migration to ADABAS was certainly a step up in database functionality, the fact that we now also need to support the various aforementioned relational databases in addition to ADABAS (as our enterprise database), clearly indicates that we need to take a hard look at our overall database support strategy. Do we continue to manage these distributed platform databases as they appear from within our Administrative departments or should we take a step back and understand whether the needs of our constituents might be better served via a more centrally managed database environment—be it a single database entity or a more minimally supported set of database entities than we are trying to support today?

Summary

As noted above, in the mainframe world there are very few choices! By contrast, as recommended by our most recent imperative entitled: "Web Based Infrastructure Strategy", we are already planning to expand our operating system support to include two additional mainframe operating systems (i.e. z/VM and zLinux) and one additional Intel-based operating system (i.e. VMWare). Compounding this further is the fact that we will also continue to be required to support Windows Server 200x and—to some degree—integration of our desktop operating systems, Windows 200x and Mac OS X. In the database support area, in addition to continued support of our existing mainframe ADABAS database environment, we also currently support three of the industry’s most popular distributed system relational database platforms, namely Microsoft SQL, Oracle and IBM's DB2. When we get right down to it, it quickly becomes evident that we are placing an extraordinary amount of burden on our already resource-constrained operating system and database management teams!

Armed with this as background information, this imperative will attempt to delve deeper into the three areas noted. However, because of the research results garnered thus far, we will not persist in any individual assessment of a particular mainframe hardware environment—except as it may pertain directly to a specific need to do such research based on a potential Enterprise-wide change in operating systems. Therefore, based on results obtained to date, this imperative will henceforth assume that unless further research shows that we should pursue a change of operating systems on a global scale, IBM's zSeries hardware will continue to be our mainframe architecture into the foreseeable future.

The product matrices (provided in this report as Appendices D through L) have been pared down to show the relevant cross-section of hardware, operating systems and databases that could potentially be combined in an administrative computing environment. Literally hundreds of entries in each of the three categories were initially analyzed. The criterion that was used to finally narrow down the possible combinations was to keep only the individual entries that can be combined together with at least two or more other entries. A very few noted exceptions to this were allowed because of the industry-wide popularity of a particular product. This should not imply that these products be given special consideration—it merely provides for completeness in the overall analysis and is consistent with industry trends. In the end, corroborating evidence included in this section and the “Additional Observations” (reference Appendix B) and “Issues” (reference Appendix C) sections will be used to either eliminate or recommend any of the entries or combinations of entries. (Reference the “Potential Outcomes” section in the report).

Appendix B: Additional Observations

Microsoft DataCenter may be considered an Enterprise level operating system environment but it carries with it some very stringent change management restrictions. In order to remain "DataCenter certified", these change implementation rules must be followed. This would place a severe limitation on the frequency with which changes

13

may be made to this environment. On this criterion alone, based on the frequency of requests for changes to our central administrative computing environment, Microsoft DataCenter should not be considered as a viable Enterprise level operating system platform.

Microsoft Windows Server 200x is currently highly integrated into our mid-tier application server environment. As a result of a previous imperative entitled: "Web Based Infrastructure Strategy", it should be clearly noted here that the Windows Server 200x operating system should not be considered as a viable Enterprise level operating system platform.

Apple's Mac OS X (and its predecessor Mac OS 9) also will not be considered as Enterprise level operating system platforms—along with Microsoft Windows desktop operating systems—simply based on scale.

Novel NetWare is an operating system that provides specialized operating system functionality and as such will not be considered as an Enterprise level operating system platform.

Hitachi's VOS/xS operating systems are e-Business compatible, Web-enabled and support both CORBA and XML environments.

The fact that we are a University and are considered an "Open Environment" should not also imply that administrative computing must support so many different technology platforms; that should be left to Academia for teaching and learning. A “Business Computing Model” differs immensely from an “Academic Computing Model”.

AIS and other ITS groups should continue to work together to share knowledge, taking advantage of additional resource allocation wherever the opportunity presents itself. Philosophical restrictions should not be imposed on one another that would hinder the ability to share resources. At the same time, we should share and/or merge functions only where it makes sense from tactical, strategic and budgetary viewpoint.

Web enablement is key! A significant goal for AIS should be to displace all 3270-screen type applications. Once we have migrated to a more Java-oriented application development environment, back end hardware, operating systems and databases should more easily be able to be interchanged/exchanged. In the interim, along with consolidation of servers, consolidation of other areas—where it makes sense—should also be explored.

It would appear that for the near future at least, support for multiple operating systems and databases will be required. However, we need to start to get a handle on the continued proliferation of these new environments. We cannot just keep on "spreading ourselves thinner".

Appendix C: Issues

In order to come to some of the conclusions produced in this document it was necessary to obtain corroborating evidence. In this light, interviews were conducted with each member of the selected Virtual Team. This cross-section of AIS representatives served to provide a comprehensive list of the issues that need to be addressed before,

14

during and after any effort to make a major change in infrastructure. The following section describes the issues that would have the most impact in making such an architectural change decision.

Production Batch JobsOne consistent general theme that presented itself throughout the investigation was that in order to replace the mainframe as the key hardware platform for administrative computing, we would be compelled to spend an enormous amount of energy redefining the business processes that require us to have such a large dependence on the execution of production batch jobs. There are an estimated 4000-4500 of these production procedures. An estimated 90% of these procedures are required to satisfy some type of business processes. For example, we generate/produce official University correspondence letters to be printed on special letterhead print stock, official transcripts for students’ perspective employers, special labels for various uses (including mailing address labels), payroll checks and/or check stubs, billing reports, email alerts, other special reports for various internal and external customers and other print for special requests. While we continue to decrease the printing of reports by shipping these off to COLD, we would need to work to move away from the more specialized printing—in particular, impact printing.

Business RequirementsIt could be as simple as a financial decision that drives us to replace any of the major infrastructure components being investigated. The decision could rest solely on the financial viability of a company or it could be closely tied to a continuous increase in costs incurred as a result of vendor pricing changes. Regardless of the reason we might decide to change any of our infrastructure components, it will be necessary to do a comprehensive analysis of the business requirements that could drive us in a particular technical direction. This would give us a better chance to identify particular software and/or hardware that could satisfy specific business requirements. Unless it is determined that there is a strong reason to recommend a specific hardware or software component, there needs to be a good understanding of our target or it will be difficult to build an infrastructure to support it. In fact, it is a more reasonable approach to start with identifying requirements, determine the appropriate software and finally, identify the hardware platform that can support it. While there continues to be interest from our customers to have direct access to our primary data repository, we cannot provide this for security reasons. Therefore, any change in database architecture needs to take this type of requirement into account. AIS will need to provide a better user interface, especially if we intend to establish and maintain a set of standard business rules.

Historical Business ProcessesDuring the many years that administrative computing has been utilizing the mainframe a tremendous amount of experience has been developed in mapping business processes to computer infrastructure. There are some pluses and minuses associated with this. Certainly, this type of experience provides an invaluable support tool. On the other hand, over time attrition of experienced employees (i.e. turnover) makes maintenance and support of these processes difficult. There continues to be strong support that “change control processes” similar to those developed for the mainframe environment should be implemented for distributed systems.

MiddlewareRegardless of any selection of a combination of hardware and/or software components, there will always be a need to provide specialized interfaces to integrate the disparate platforms we are obliged to support today. Unless we determine that we can support all of the administrative computing requirements we are asked to fulfill on a single hardware and operating system platform, we will always be required to write interface code at some level. However, if we are able to limit the number of different vendors required to provide the infrastructure, we stand a better chance of reducing our dependence on these types of “home-grown” integration software components. It is certainly valid to state that even though we may have a single vendor for our hardware and software infrastructure we would be able to maintain and support a completely open standards service environment from the perspective of the users of our services. We are in the process of replacing our Hydra middleware interface with Software AG’s EntireX because the middleware technology behind Hydra is no longer being supported. This all needs to be transparent to our users. A similar replacement analysis needs to be done with the SmallTalk programming interface as we continue to face issues with integrating our middleware infrastructure with external security functions.

15

NATURAL ProgramsIn any discussion re changing our database software the number of NATURAL programs we support is quickly raised as an issue. However, it is not necessarily the number of programs that is the problem but perhaps more so the specific business process function(s) that each program performs. The real challenge seems to be in identifying all of the functionality that must be replaced (or rewritten) to interface with a new database. This may be tempered by the fact that there are other databases with which NATURAL programs can interface. Any change of database software would require a complete analysis to identify the scope of this type of effort. In addition, the EAI imperative has already indicated that there needs to be a concerted effort to modularize our business application programs. It has also been determined that Java will become the new application development programming language of choice.

Performance and Scaling FactorsOne of the most critical issues we have to address in any decision to change infrastructure is in the area of performance and scaling of our applications. Currently, it is too early to determine what level of impact our EAI decision to adopt Java and WebSphere as our application architecture may have on our existing processor capacity.

Enterprise Application Integration (EAI)The promise of the EAI initiative is that once completed we will have established a new, modularized set of application functions (i.e. programs) written in Java. At this stage, however, we cannot make any kind of assessment or accurate prediction with respect to any operational impact that this new environment might eventually have—if any. The only estimate that has been attempted is a potential time frame of 3-5 years to be ready to change environments—from a NATURAL program rewrite perspective. However, it should be noted that once the EAI initiative is completed, it should become much easier to change infrastructure components.

Training Requirements Another significant impact of changing our infrastructure environment is training requirements. If we change hardware, the operations staff will require significant training. This is an area where we have an established experience level, measured in years. It would be an arduous task to train an IBM mainframe operations staff in any other platform. A major change in software will have a similar training impact on systems staff—both in operating systems and database management. From an applications development perspective, we are already stretched thin. Re-engineering our NATURAL environment will be a long, difficult process. If we change hardware and software infrastructure at the same time, we will be placing an inordinate amount of pressure on this part of the organization. Re-tooling and re-staffing require significant investment in training—both in time and dollars.

Distributed DatabasesThe proliferation of databases outside of the mainframe environment has generated concerns re the ability to continue to support several databases with a small staff. There seems to be no clear-cut direction in choosing some of these database environments. Developers struggle with design issues and a lack of consistent tool sets available to manage disparate relational databases. There is also a problem finding consistent database support products that run on the same platform as our existing variety of databases. In support of our EAI effort to move to IBM’s WebSphere environment, their recent acquisition of Rational tools is receiving accolades for being a comprehensive set of application design tools. Making changes to any one of these databases requires training (reference “Training Requirements” section). Queries into these databases and writing interface modules for data extraction purposes present database integration issues.

ADABAS Data Access While there appear to be tools available that would provide requested access to our ADABAS data repository, we seem very slow to adopt these. Much of the blame for this can be placed directly on existing workload. We need to provide a better ADABAS interface than we currently provide via the Generalized Interface. We need the ability to package NATURAL programs as Web Services. We need to determine how we can call NATURAL via SOAP. Users no longer want “green screen” functions. This will require re-engineering of applications that access ADABAS. There are also several inherent stumbling blocks that must be overcome whereby we have database files

16

that do not integrate well with the distributed relational databases. We need to determine the value of these files and whether changes to our existing NATURAL program environment are sufficient to warrant changing them vs. moving to a programming model that supports this type of cross-platform integration. It needs to be determined how important time is as a factor in fulfilling business requirements.

Risk Assessment Based on Existing Investment in Mainframe TechnologyIt simply cannot be ignored! We have a significant investment in mainframe technology. This investment includes people, hardware and software. In order to suddenly opt to go a different direction in hardware and/or software technology, it is extremely important to assess the risk involved to the business operations of the University. A market trends analysis should be done to determine what the majority of businesses are doing in this space. As a University, the adoption of “open standards” based computing paradigm makes sense. However, we need to determine whether that is in fact a proper direction to take from an administrative computing perspective.

SecurityNo analysis can be complete without addressing security concerns. Each time we build a new interface be it via hardware or software, we introduce a level of risk that our security infrastructure will be weakened. The mainframe provides a very tight level of security by its very nature and we have spent considerable time developing the many interfaces required to maintain a fully secure operational environment. Making any major change in infrastructure will force us to take a long, hard look at security requirements and ensure we can match these to whatever the new architecture might be.

Reliability and StabilityAnother very important aspect of our long-term dependence on a mainframe environment is the fact that we have become accustomed to having a very reliable and stable environment. Any venture into a new hardware and/or software architecture demands that we can be assured that we will be able to maintain these valuable, intrinsic characteristics.

Database FunctionalityCurrently, we support a mixed non-relational and relational database environment between the mainframe and distributed systems. Our mid-tier database systems are mostly copies of existing mainframe data used to enable access via relational database tools used by our customers. Minimally, we need to understand these requirements and determine whether or not our existing database infrastructure is suited to support the business requirements of the future. The basic premise here that needs to be determined is whether we would be better served by migrating to a completely relational database environment.

Cultural Changes and LogisticsIt is a significant challenge to undertake a decision process of this magnitude. For many, it is simply intimidating to even contemplate major changes in infrastructure. Yet if we continue to maintain our status quo operandi will we be able to maintain an even balance among support structure and ongoing fulfillment of future business requirements? We also need to maintain a balance between performance, scalability, security, functionality, manageability and cost. As we continue to promise our user community that we will strive to improve their access to the central data repository, we will need to be able to provide a solid internal support infrastructure. We need to employ a better change management capability. We need better tools with which to manage the ever-changing systems infrastructure. We need to improve our systems monitoring capability. If we are to ever attain a fully managed set of business rules that will allow us to maintain and satisfy service level agreements, we need to provide the tools, time, training and resources—both people and equipment—to effectively do so.

Vendor IssuesAs we continue to generate new vendor relationships we need to be wary of their ability to support the environment we create. Vendor relationships are very important. They can change their pricing models at a whim. We need to be sure we can withstand sudden increases in cost. We also need to be better prepared for the potential failure of a product and/or the financial collapse of a vendor. This is a very stark reality in today’s data processing world.

17

While moving toward a single vendor for support of a large part of your infrastructure certainly has its merit, there is another side to this that should make us wary of things like sudden changes in pricing models. When we make recommendations for product selections, we should always have two choices at a minimum (where feasible). This way, if something does happen, we can have a fallback plan.

Appendix D: Databases Cross-Referenced to Hardware (Part 1)

18

Appendix E: Databases Cross-Referenced to Hardware (Part 2)

19

Appendix F: Databases Cross-Referenced to Operating Systems (Part 1)

20

Appendix G: Databases Cross-Referenced to Operating Systems (Part 2)

21

Appendix H: Hardware Cross-Referenced to Databases

22

Appendix I: Hardware Cross-Referenced to Operating Systems

23

Appendix J: Operating Systems Cross-Referenced to Databases (Part 1)

24

Appendix K: Operating Systems Cross-Referenced to Databases (Part 2)

25

Appendix L: Operating Systems Cross-Referenced to Hardware

26