DRAFT
ITS Responsibilities
There are many components to ITS: The operating system (either Windows NT or Linux), the Apache Web server, the ITS server components (WGate and AGate), and SAP R3 itself.
Each level of these components has different pieces. This document will start at the top level and drill down from there, where granularity would be beneficial.
Operating system:
The installation and maintenance of the operating system will be done by ASST. This includes initial installation, ongoing monitoring for disk space, security, etc. Any upgrades and/or system patches will be coordinated with FSS and R3-Admin. Basic configuration of the system should be mutually agreed upon by ASST, FSS, R3-Admin, and ITAG. This includes, but is not limited to things like daemons (Services) enabled, open ports, software installed, and operating system version. A configuration document will be written by the its-so team lead by Peter B. Kelley and will be available as part of http://web.mit.edu/its-alive/sap-docs/ITS_Config.html. The NT document should be complete before the productive rollout of ITS on June 1, 2001.
Apache Web Server:
The main components of the Apache server are: The server itself, SSL, and the ITS components that are part of the web environment (Wgate).
Installation and configuration of the Apache software will be done by ASST. This includes all of the add-ins necessary to enable SSL and user certificates. FSS will assist as needed with any SSL/Certificate issues that may arise, since these are critical to the overall security of ITS. The ITS component of the Apache server (currently the WGate Apache Module) will be the responsibility of FSS. There are also many SAP specific configuration requirements in the WGate.conf file, so it is best to keep responsibility for this in the FSS area. The actual installation of the module and configuration file will be done by ASST, with assistance from FSS (see the current draft at http://web.mit.edu/its-alive/sap-docs/ITS_Config.html)
ITS Application (WGate and Agate):
The installation will be done by ASST, the initial configuration will be defined by FSS, R3-Admin and ASST working together. Transactions deployed to ITS will be the responsibility of FSS and the transaction developers. The current method of deployment is through the SAP Web Publishing functionality of SAP (this may change in the future, depending on availability in Linux, and security concerns). FSS will need to be involved in any troubleshooting of the ITS environment, and should have the skill required to evaluate the problem (i.e. OS, Apache, WGate, Agate, network, SAP transaction etc). An FSS resource will need to be available to the developers, business analysts, and ASST to advise on platform, web server, security, and infrastructure issues on an ongoing basis.
Transactional Development:
No transactions will be deployed via ITS without management approval. Once approved the transaction may be either published to the web as delivered from SAP, or require FSS directed development. FSS will coordinate all development efforts involving the ITS plateform. All ITS development will follow the FSS defined Development standards (http://web.mit.edu/sapr3/dev/its_dev_standards.html), and will need to follow the FSS Review process. ITS transactions will also need to comply with the QA and testing procedures defined by the FSS QA group.
Training, support and documentation:
Based on the current FSS scope, documentation & training responsibilities
are confined to end user support, not project team or technical support.
Both functions should be included early in the process to ensure effective
and timely delivery of end user support at rollout and ongoing.
For training the most likely delivery methods are large-scale demos and/or
web- or computer-based training. Documentation delivery could follow
several models which will affect staffing: web-based documentation and/or
documentation embedded in the ITS transactions. (The documenter could be
combined with the Web Resource, depending on skill set, volume of work, and
delivery model.)
End user support will be handled in much the same way as SAP support is handled now. The BLT’s will act as the front line representatives, and problems will be refered to appropriate people in FSS, R3-Admin, and/or IS as necessary.
SAP Configuration:
This will be done by a representative of R3-Admin with the assistance of FSS personnel if necessary. This configuration includes, but is not limited to: Web Publishing configuration, Certificate registration and configuration, User setup and authorizations, and SNC configuration.
ASST: At least 1 person (plus backup) with:
Expert OS person (NT or Linux)
Knowledge and understanding of Apache Server and SSL
Basic understanding of SAP, Kerberos, and SNC
Initial effort will be high, after deployment, and assuming that ‘Web Publishing’ remains an option, ongoing support should primarily be log monitoring (event log, backup logs, application logs), disk space monitoring, and problem resolution. There may be a requirement for system performance and Web server statistic reporting.
FSS Infrastructure: At least 1 person (plus active backup) with:
Basic understanding of OS (NT or Linux)
Knowledge and basic understanding of Apache Server and SSL
Expert understanding of SAP, Kerberos, and SNC
Initial effort will be high, after deployment involvement we be in an advisor roll to both ASST as necessary for problem resolution, and FSS as programmers require guidance on the platform, web-server, infrastructure aspects of ITS. (This person could also probably be involved as a developer as well)
FSS Developer: At least 1 person (per transactional area) with:
Basic understanding of Apache/Web server technology
Knowledge of ITS infrastructure
Knowledge of HTML, Business HTML and JavaScript
Knowledge of ABAP Transactional Programming
Knowledge and understanding of MIT development standards and ITS policies
Initial effort to develop and deploy a transaction could be very high; support of transaction on going should be significantly less. This person would probably be used on other ITS projects during the support phase.
Training & Documentation: Part of 2 people in FSS:
Trainer requires:
Professional training skills
Basic understanding of business process and procedures
Some familiarity with the ITS project & deliverables
Documenter requires:
Professional documentation skills
Expert understanding of HTML/Java Script
Basic understanding of business process and procedures
Some familiarity with the ITS project & deliverables
R3-Admin: Part of 1 person with:
Expert SAP Basis knowledge
Basic understanding of ITS and Web Publishing
Expert CTS understanding
(Certificate import stuff?)
Initial effort will be moderate in setting up and maintaining certificate information and initial SNC connections for ITS servers. Ongoing effort concerning Change Transport with Web Publishing is an open issue. Also there is an unknown with Certificates (i.e. affect of anonymous certificates).
Web Resource: Part of 1 person in FSS with:
Basic understanding of ITS and its web environment
Expert understanding of HTML/Java Script
Knowledge of image manipulation
Initial effort will be moderate in coming up with common scripts and images for the html pages. As more transactions are deployed to the web; common Java Scripts will be used thereby lessening the load, but there will always be a need for some custom JavaScript/Image development. (Portal maintenance?)
HTML GUI: If/When MIT decides to roll out the HTML GUI then there will be significant changes in staffing and system resourcing. Since most of the load on the SAP systems is currently GUI based, the burden is placed on the app servers and the db server. If the HTML GUI is brought into the picture, this load would be partially delegated to the ITS server. This would probably increase the number of front end servers needed, so would impact both ASST, and R3-Admin. Since some of these new servers would be ITS servers, this would probably increase the resources needed to support them in FSS. Also support becomes more complicated in this environment, so the BLT would need to be involved. While training should become simpler because there will be only one ‘look and feel’. GUI deployment should become simpler (since there would be no deployment of the client software).
Multiple ITS Servers with load balancing: This may be a near term concern. We may need to support a very large user load for the ‘open enrollment’ period. Since we have never had to support this many users, we do not know what will be required both of the ITS box as well as from the App server side.
MySAP/SAP Workplace: I do not know enough about these products to comment, but I am sure that deployment of this will require both resources and hardware.