Kuali Student Service System. Program Charter. Prepared for: Kuali Student Service System Board

Transcription

1 Program Charter Prepared for: Kuali Student Service System Board June 2007

2 Program Charter Document Information and Revision History Document Revisions Version Date Author(s) Description of Change 0.1 October 12, Cath Fairlie Draft outline for document November 27, 2006 Cath Fairlie Updated in preparation for Founders Workshop. Draft approaches fleshed out for discussion. 2.0 January 8, 2007 Cath Fairlie Updated with feedback from Founders Workshop and Technical/Functional Workshop 2.1 April 23, 2007 Cath Fairlie Updated with feedback from Planning Workshops 2.2 May 28, 2007 Cath Fairlie Updated after Functional Planning Workshop 3.0 June 18, 2007 Cath Fairlie Final Version Kuali Student Program Charter June 18, 2007 Page 2 of 76

3 TABLE OF CONTENTS Kuali Student Service System Program Charter 1 INTRODUCTION BACKGROUND AND OVERVIEW PURPOSE OF THIS DOCUMENT PROGRAM CHARTER APPROVAL PROGRAM OBJECTIVES KUALI STUDENT SERVICE SYSTEM VISION PROGRAM OBJECTIVES KEY SUCCESS INDICATORS FUNCTIONAL SCOPE AND APPROACH DELIVERING THE FUNCTIONAL VISION FUNCTIONAL SCOPE Tier 1 Functional Scope Tier 2 Functional Scope Tier 3 Functional Scope Functionality Out of Scope of Student Service System INTERNATIONALIZATION Multi-Language Support Multi-Currency Support Support for International Credentials Compliance with International Legislative Requirements TECHNICAL ARCHITECTURE GUIDING PRINCIPLES FOR THE TECHNICAL ARCHITECTURE OTHER PRODUCT IMPLEMENTATION CONSIDERATIONS TESTING STRATEGIES QUALITY ASSURANCE REVIEWS Project Management Practices Architectural Reviews Code Reviews LICENSE MANAGEMENT PRODUCT DOCUMENTATION IMPLEMENTATION SUPPORT PRODUCT SUPPORT AND COMMUNITY SUSTAINMENT PROGRAM DELIVERY PHASED APPROACH SERVICE ORIENTED ARCHITECTURE CRITICAL SUCCESS FACTORS PROJECT TEAM TRAINING MODULAR DELIVERY PROGRAM PHASES Preparation and Planning Phase Application Architecture Phase Service Modeling Phase Service Contract Design Phase Technical Architecture Phase Development Infrastructure Phase Develop Configuration Application Phase Software Design and Development Program Management & Communication Kuali Student Program Charter June 18, 2007 Page 3 of 76

4 Program Charter Product Release & Implementation Support DELIVERABLES AND MILESTONES PROGRAM TIMELINE PROGRAM ORGANIZATION PARTNERSHIPS Founders Partners Adopters Other Partnerships and Stakeholders PROGRAM TEAM ORGANIZATION ROLES & RESPONSIBILITIES RECRUITMENT FOR POSITIONS PROGRAM COSTS & BENEFITS BENEFITS COSTING ASSUMPTIONS COSTS SUMMARY FUNDING CONTRIBUTIONS PROJECT MANAGEMENT PROJECT PLANNING STATUS REPORTING CHANGE REQUEST AND ISSUE MANAGEMENT Change Request Procedure Issues Management Procedure WEEKLY TIME REPORTING PROJECT DOCUMENTATION STRATEGY COLLABORATION TOOLS EXTERNAL COMMUNICATION APPROACH RISK MANAGEMENT APPENDIX A DELIVERING THE FUNCTIONAL VISION APPENDIX B DETAILED FUNCTIONAL SCOPE APPENDIX C TECHNICAL ARCHITECTURE CONSIDERATIONS APPENDIX D EDUCATIONAL COMMUNITY LICENSE APPENDIX E TECHNICAL ARCHITECTURE DELIVERABLES & APPROACH APPENDIX F APPLICATION DEVELOPMENT DELIVERABLES & APPROACH APPENDIX G FOUNDERS PROFILE MATRIX APPENDIX H DETAILED COST ESTIMATES APPENDIX I COMMUNICATIONS STRATEGY APPENDIX J PROGRAM RISK ASSESSMENT Kuali Student Program Charter June 18, 2007 Page 4 of 76

5 Program Charter 1 Introduction 1.1 Background and Overview Colleges and universities require effective Student Information Systems (SIS) to manage student enrollment, degree audit, financial aid, course management and other student and teaching related administrative processes and services. In recent years, user expectations for easy-to-use, on-line services have increased and the quality of these services has become a significant differentiator for students and faculty. In response, institutions have expended considerable resources to expand the functionality provided by these systems and to increase their usability. Demand for additional functionality, enhancements and modifications often outstrip the technical resources available to deal with these diverse needs and desires. The student information systems used by many institutions today are components within large and complex Enterprise Resource Planning (ERP) systems, which are generally very expensive to implement and maintain. These systems also make it difficult and expensive to support differentiated processes and services that reflect different types of institution, with different goals and missions. In addition, the recent corporate acquisitions and consolidation in the ERP space have caused concern in the administrative software market within higher education. The sustainability and desirability of the big, monolithic, and expensive ERPs suites that currently serve higher education is now uncertain. Some institutions with systems they have developed in-house believe there is an increasing risk in continuing to develop and support these systems on their own, but would like to continue their in-house development along with others in a larger community. They strongly favor an incremental replacement using modular Student Service System (SSS) components as an alternative to the installation of a large, monolithic SIS system. Over the past year, discussions among higher education institutions about a next generation Student Service System led to a feasibility study funded by the Andrew W. Mellon Foundation to assess college and university interest in a next generation, open source, Student Service System. 1 This study, completed July 2006, found a high level of interest in college and university investment in a next generation SSS. A significant number of institutions would like to use new modules, developed as part of an SSS project, to add functionality or features to existing systems, while other institutions need to replace systems that use old technology that is becoming increasingly difficult to support. Inspired by the results of the feasibility study, a series of formal and informal meetings, focus groups, and workshops were held between March and October 2006 to help build the initial community of interest for the SSS project, and to provide diverse input on the vision and the functional and technical underpinnings of the project. In November 2006, a consortium of 5 institutions was formed to develop a Community Source Student Service System. This consortium included The University of British Columbia; Carnegie Mellon University; The University of Maryland, College Park; The University of California, Berkeley; and San Joaquin Delta College. The consortium has since been expanded to include 1 Open Source Student Service System Report on the planning grant from the Andrew W. Mellon Foundation. This report can be found at: Kuali Student Program Charter June 18, 2007 Page 5 of 76

6 the Massachusetts Institute of Technology and Florida State University. Kuali Student Service System Program Charter It was agreed that this community source system would be developed under the umbrella of the Kuali Foundation. The benefits of this affiliation are that the community source Student Service System can: Use and expand upon the existing Kuali Foundation organization structure Benefit from their communication and technical infrastructure Contribute to the development a full suite of community source applications that can be adopted by any higher-education institution The convergence of the need for new functionality in a next generation Student Service System with the need to find alternatives to ERP systems, and to provide increased support for homegrown systems, have created strong and wide spread interest in a next generation community source SSS. The growing maturity of SOA and web service technologies, and the proven track record of community source projects, makes this the right time to launch the Kuali Student Service System (Kuali Student). 1.2 Purpose of this Document This charter provides a description of the Kuali Student Service System (Kuali Student) Program, defining its scope, objectives and overall approach. It serves as the agreement between the Program Team, the Program Board and the principle Partners, stating what the program is committed to deliver and outlining the deliverables, time constraints, roles and responsibilities, resources, and standards. The Charter serves as the baseline reference document for the Kuali Student Service System Program, against which all Change Requests will be assessed and measured. Taken together, the Program Charter and Change Requests will define the scope of the program. A secondary purpose of this Charter is to document the overall project management methodology and organizational structure that will be used to govern the Kuali Student Service System Program. The Program Charter is the first point of reference for all personnel on the Kuali Student Service System Program. As a team, we share the responsibility to ensure that we follow the practices outlined in the Charter. We also have additional responsibility to make recommendations for improving the way the Kuali Student Service System Program team functions. Feedback is encouraged and appreciated. 1.3 Program Charter Approval The signature of the Kuali Student Board Members and Partner Members below indicates that this document has been reviewed in full and that the Members are in agreement with the items included. In addition, they have made known to the Project Director any factors that they are aware of that would affect the successful completion of the program. Board Member: Signature: Ted Dodds, CIO & AVP Information Technology The University of British Columbia Date: Kuali Student Program Charter June 18, 2007 Page 6 of 76

7 Program Charter Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Board Member: Signature: Brian Silzer, AVP Enrolment Services and Registrar The University of British Columbia Shelton Waggener, Associate Vice Chancellor & CIO University of California, Berkeley Date: Date: Susie Castillo-Robson, Associate Vice Chancellor Admissions & Enrollment University of California, Berkeley Jeff Huskamp, Vice President and CIO University of Maryland, College Park William McLean, Associate VP Budget & Finance University of Maryland, College Park Larry Conrad, AVP for Technology Integration and CIO Florida State University John Barnhill, AVP Enrollment Management Florida State University Date: Date: Date: Date: Date: Lee Belarmino, Associate Vice President Information Technology San Joaquin Delta College Chris Coppola, rsmart San Joaquin Delta College Date: Date: Kuali Student Program Charter June 18, 2007 Page 7 of 76

8 Program Charter Partner Member: Signature: Partner Member: Signature: Program Director: Signature: Jerrold Grochow, VP for Information Services and Technology Massachusetts Institute of Technology Joel Smith, Vice Provost and CIO Carnegie Mellon University Catherine Fairlie Program Director Kuali Student Service System Date: Date: Date: Kuali Student Program Charter June 18, 2007 Page 8 of 76

9 Program Charter 2 Program Objectives 2.1 Kuali Student Service System Vision A broad and compelling vision is necessary to ensure that Kuali Student delivers all the potential benefits of a next generation system. The vision sets out to achieve the following: To support students and other users by anticipating their needs; help them to make choices, set goals and track their progress; and reduce the time it takes them to complete administrative tasks. To provide students with seamless access to the resources they need: within the institution across programs, across campuses, and across institutions. To support a wide range of learners and learning activities, in a wide range of institutions, and make it as simple as possible to provide support for new types of learner, activities and programs. To support a wide range of academic and related business processes, including those that cross departments, systems and institutions, in ways that work best for each institution, and make it easier, faster and less expensive to change existing processes and introduce new ones. To build a system that complements human interactions, releasing staff from repetitive clerical and administrative tasks, and allows them to provide higher value support and services to students, faculty, and other people who need it. To provide highly scalable support for users and the execution of processes, so that high levels of service can be provided, with very low incremental increases in cost, to an increasing number of users, each of whom has access to a growing range of choices and services. To achieve sustainability through community source distribution and wide spread adoption. It is hoped that the Kuali Student Service System vision will eventually generate multiple projects or programs with different sponsors or investors each with a specific charter and project manager. This charter will define a scope of work to be undertaken by the 5 founding institutions: The University of British Columbia; The University of Maryland, College Park; The University of California, Berkeley; Florida State University; and San Joaquin Delta College. It is a 5 year program using a phased approach to development with regular software releases. In order to avoid confusion, the following terms are defined: 1. The Kuali Student Service System (Kuali Student) the next generation, community source Student Service System. 2. The Kuali Student Program refers to the program and deliverables outlined by this program charter. 3. Kuali Student Software or the Software refers to the software developed as one of the key deliverables of the Kuali Student Program. The scope of this software is defined below and is generally considered to include the core or high-priority modules required for a fully functioning Student Service System. Kuali Student Program Charter June 18, 2007 Page 9 of 76

10 Program Charter 2.2 Program Objectives The specific objectives of each Founding institution for participating in the development of Kuali Student will be very different. However, the common objectives that will achieve the vision of the Kuali Student Program can be stated as follows: To develop a next generation Student Service System architecture that follows the principles of Service-Orientation, implemented using Web Services. This architecture will support the development of modular, technology neutral applications, that can be integrated with existing systems - where open source, custom developed, and commercial applications can be combined. To integrate the architectures of Kuali Student and the other Kuali products (where possible without sacrificing the vision) in order to make it easy for institutions who are implementing multiple Kuali products. To develop the Service Contract specifications for the services required to implement the Student Service System. This will enable development work to be completed by a large community, not just the originating Founders. To develop, and release for implementation, a software product consisting of a set of Services that have been defined to be the core functions of a next generation Student Service System - Kuali Student. To define and publish standards for development that can be used by other members of the community to develop Services that are not within the scope of the core product. To ensure that IP and license compliance is maintained throughout all Kuali Student development. To ensure the core Services of Kuali Student are successfully implemented by the Founding Institutions. To promote the adoption and implementation of Kuali Student by a wide variety of educational institutions within North America and internationally. To build a community of interest that will sustain future maintenance, enhancement and development of the product and to develop a pool of highly qualified developers. To define product development, support, and communication processes that will be used to assist the community to implement the software and to provide operational support for the product. To continue to evolve the technology and architecture of Kuali Student over time to keep up with new industry standards, tool releases and trends. 2.3 Key Success Indicators The following key success indicators have been defined in order to measure the success of the Kuali Student Program: 1. The core Services of Kuali Student have been successfully developed and released for implementation. The program was completed in a timely manner so that Applications were released on a frequent basis, generally according to the initial program schedule set out in the Program Charter. The cost of executing the Program was within the expectations of the Founding institutions. 2. Feedback from students, faculty and administrators on the system experience The system enables students, faculty and administrators to perform their business functions in a simple, easy to use manner. Feedback obtained by survey of the groups of constituents is very positive. Kuali Student Program Charter June 18, 2007 Page 10 of 76

11 Program Charter 3. Adoption rate by colleges and universities One year after the completion of the 5 year program, the relevant core modules of Kuali Student have been implemented in production by all 5 Founders. 20 other institutions have implemented 1 or more modules in production. 50 other institutions are in the process of implementing 1 or more modules of the software. 4. Partner Institutions are able to develop components of the system using published standards. The Kuali Student Architecture, Service Contract Specifications, and Development Standards have been published to the community. Partner Institutions have used these materials to successfully develop and release at least one non-core module that integrates easily with the Kuali Student core and follows Kuali Student development standards. 5. A viable support organization exists - Procedures are in place to submit and evaluate software enhancements. The community of developers is responding to product bugs and issues in a timely manner by developing fixes. Quality Assurance procedures are being adhered to for packaging and releasing these software fixes. The support organization has successfully developed, packaged, and released at least one updated version of the software. 6. Implementation Services are available to new adopters Either commercial vendors or the Community have responded by developing and sharing implementation materials. New adopters have access to resources that will assist them with their implementations. 7. A healthy vendor community has developed around Kuali Student. Vendors are available to provide Implementation Services, Support Services and are actively working to develop new modules or interfaces to other software systems. 8. Re-usability of service modules, and flexibility to adapt to business processes from multiple organizations. This can be measured by the number of process agnostic services that are re-used within the applications modules. 9. IP and license compliance. All license agreements (CLAs) have been signed before development starts and there is 100% compliance to the CLA's and 3 rd party licenses before product is released. Kuali Student Program Charter June 18, 2007 Page 11 of 76

12 Program Charter 3 Functional Scope and Approach 3.1 Delivering the Functional Vision Seven elements are critical in the design of the system to ensure that the functionality provided in Kuali Student delivers the vision: 1. new, high level entities that make it easier to introduce new programs and approaches to learning; 2. a concierge function that helps students by using information about their plans and accomplishments, available resources, and the institutions rules and opportunities; 3. the use of workflow and rules engines to implement and improve business processes, make the system highly scalable, and allow the rapid investigation and evaluation of multiple scenarios, using agreed rules and criteria; 4. the ability to configure the system, using the workflow and rules engines, to support processes developed at each institution, rather than the processes that the system developers choose to support; 5. a modular, loosely coupled, standards based architecture, that will allow Kuali Student to work with existing and new applications (and, conversely, would allow a third party application to be used in place of one of the Kuali Student Application modules); 6. appropriate access to data and information, with services to make it simple for users to find and use the information they need, when they need it, in the form that is most useful to them; and 7. a system design that supports internationalization, i.e. the use of different languages and currencies, and provision for different educational models. Appendix A provides a detailed description of each of these design elements. 3.2 Functional Scope The following section defines the scope of work to be undertaken by the 5 founding institutions: The University of British Columbia; The University of Maryland, College Park; The University of California, Berkeley; Florida State University; and San Joaquin Delta College. It is a 5 year program using a phased approach to development with regular software releases. The scope of the software to be developed by this program includes the core or high-priority modules that the founding institutions have determined to be part of a fully functioning Student Service System. This functionality has been grouped into 3 tiers of functionality according to the development priority. Tier 1 functionality includes the Core modules that are critical and fundamental components of a student system. Tier 2 functionality includes modules that are important for a fully functioning student system, but they have a lower priority for development or they may have large components that can be satisfied by an existing best of breed software product. Tier 3 functionality includes modules that that founding institutions have determined to be out of scope for this program. Partner institutions or commercial vendors are encouraged to define Kuali Student Program Charter June 18, 2007 Page 12 of 76

13 Program Charter projects to develop software modules that fall within Tier 3 - outside the scope of this program, but complementary to the core system. The following section outlines the functionality that is included in Tier 1, Tier 2 and Tier 3. The functionality has been grouped into Applications that execute Business Processes that reside in traditional departmental domains. This grouping will allow the product development team to phase product releases according to development priorities. Appendix B provides a detailed description of the Functional Scope proposed for Kuali Student Tier 1 Functional Scope The following applications have been defined as part of the Tier 1 functionality Curriculum Development Application Curricula are made up of learning units. A learning unit is any learning-related activity that needs to be tracked by the institution or the learner. Learning units range from very general (a degree program) to very specific (a class assignment). All credit and non-credit learning activities, whether traditional or non-traditional, are learning units. The curriculum development application consists of the 5 business processes outlined below and is integrated with the Learning Management Systems (LMS). 1. Develop or modify a learning unit 2. Review and approve a learning unit 3. Make a learning unit available to learners 4. Assess a learning unit 5. Reports Customer Contact Application The Customer Contact Application maintains the information about persons, groups and organizations that is used throughout Kuali Student. It is responsible for communications for all other application modules. It consists of the following business processes: 1. Maintain Person Information 2. Maintain Information about groups and organizations 3. Create and manage relationships 4. Communicate with people and groups Enrollment Application The Enrollment Application enables learners to create learning plans, record (or declare) their learning intentions, and register in learning activities such as programs, joint programs, specializations and courses. It supports program and course selection, registration, class lists and grades. It supports the management of wait lists or other means of measuring demand for learning units and allocating places when demand exceeds supply. It consists of the following business processes: 1. Plan Program 2. Plan Course 3. Add/ Drop 4. Publish official academic record 5. Class list 6. Grades Entry Kuali Student Program Charter June 18, 2007 Page 13 of 76

14 Program Charter 7. Reports 8. Non-academic record Degree Audit and Academic Evaluation Application The Degree Audit and Academic Evaluation Application includes a database of requirements for all programs offered by the institution, including prior versions of these programs. It provides various on line reports on academic progress. Academic progress includes the following business processes: 1. Audit Degree (progress towards completion of some kind of program) 2. Evaluate Academic Progression (progress in meeting academic expectations) 3. Determine Academic Risk (students who are not meeting expectations may be considered at risk ) 4. Graduation Preparation Student Financials Application The Student Financials application supports the pricing, sale and purchase of both internal and external products (e.g. courses and programs) and services (e.g. athletics and library fees). It also provides access to financial planning tools for learners. It consists of the following business processes: 1. Assess fees 2. Provide access to financial planning tools 3. Invoice customer 4. Settle bill 5. Maintain customer account 6. Process Refunds 7. Reports Concierge Application Kuali Student goes beyond enabling the execution of business processes at the request of various users. As a third generation information system, Kuali Student helps users identify, evaluate, select and achieve appropriate learning goals. The concierge application helps all users achieve their desired results more quickly and efficiently without them having to know the rules. The concierge concept is implemented in 3 ways as described below. The first 2 Concierge Design Principles and Service Operating Modes are included in Tier 1 scope. The third Concierge Functionality is included in Tier 2 scope. (See Appendix B for a more detailed description of the Concierge Application). 1. Concierge Design Principles 2. Service Operating Modes 3. Concierge Functionality Configuration Application A number of the core domain objects in Kuali Student are defined at a very abstract level. For example, Kuali Student has defined Leaning Units and Learning Results rather than Courses and Grades. This abstract data model is essential to achieving a flexible system that will meet the needs of diverse institutions. Another aspect of Kuali Student that is Kuali Student Program Charter June 18, 2007 Page 14 of 76

15 Program Charter required to achieve a flexible system is the use of rules engines and workflow technology to define the business rules and the process flow. However, this means that the Kuali Student System needs to be configured to work for the specific business requirements that each institution faces. Institutions will need to identify the Learning Units that they wish to use and define the attributes for those Learning Units to the system. Business logic must be captured within the rules engines, and business process flows must be defined to the workflow engines. The Configuration Application is needed to provide a user interface to enter and define the configuration details. At system implementation time, the business analysts will work with the user community to define the business logic and rules and then enter them into the system through this specialized application. It is intended that these configuration rules (or templates) can be shared across institutions within the community. In fact, Kuali Student will be shipped with a number of templates predefined and configured in the reference implementation. Kuali Student System adopters may publish or share a repository of configuration rules to facilitate implementation by other institutions. There are 3 major functions within this application: 1. Configure Data Abstractions 2. Configure Business Rules 3. Configure Business Workflow Application Connectors Kuali Student will be delivered with standard connectors to other enterprise applications. All these connectors are delivered as web services. 1. Financial Management Information System (FMIS) connector 2. Learning Management System (LMS) connector 3. Facilities Management connector 4. Generic connectors - supply basic contact information and enrollment information to allows easy integration with other applications that are not part of the Kuali Student core such as Recruitment, Event Management, Housing, Athletics, Alumni, Library, etc Data marts and institutional reports Individual applications, such as Student Financials, are delivered with a standard set of operational reports. Beyond this there will be a need for institutional reports both for internal consumption and for external agencies (Federal, State and Provincial). Although it is not part of the core project to create a complete data warehouse, Kuali Student addresses this issue by providing: 1. Data marts (which could be implemented as views or extracts that hide the complexities of the operational database) 2. Some sample reports Tier 1 scope includes the development of data marts for Tier 1 applications Tier 2 Functional Scope The following applications have been defined as part of the Tier 2 functionality. Kuali Student Program Charter June 18, 2007 Page 15 of 76

16 Program Charter Admissions Application The Admissions Application matches prospective learners (called prospects or applicants) with learning activities (such as programs or courses) that an institution offers. The various processes (apply, acknowledge, evaluate and select) can be connected with workflow. It consists of the following business processes: 1. Apply for Admission 2. Acknowledge Application 3. Maintain Academic History 4. Maintain Non-Academic History 5. Evaluate applicant 6. Articulate transfer credit 7. Select successful candidates 8. Reports Scheduling Application The Scheduling Application schedules the various resources required to deliver the curriculum. Resources include such things as courses, exams, instructors, class rooms, facilities, and any other type of resource that one might need to schedule. It consists of the following business processes: 1. Maintain inventory of resources 2. Maintain criteria and constraints 3. Create schedules Awards and Financial Aid Application The Awards application includes all the processes to manage internal awards, bursaries/ financial aid and loans. It can support all applicable legislative and government requirements and regulations (this application will initially be configured to support federal and other regulations for Canada and the United States). It also tracks external loans on behalf of other awarding agencies. Financial planning is supported in the Student Financials application. It consists of the following business processes: 1. Maintain awards catalogue 2. Apply for award 3. Needs Analysis 4. Process loans 5. Nominate award candidates 6. Evaluate award candidates 7. Select and adjudicate 8. Offer award 9. Monitor successful candidate s eligibility 10. Disburse award 11. Report financial transactions 12. Reports to the Development Office and donor 13. Administer government loan processes Concierge Application Kuali Student goes beyond enabling the execution of business processes at the request of various users. As a third generation information system, Kuali Student helps users identify, evaluate, select and achieve appropriate learning goals. The concierge application helps all Kuali Student Program Charter June 18, 2007 Page 16 of 76

17 Program Charter users achieve their desired results more quickly and efficiently without them having to know the rules. The concierge concept is implemented in 3 ways. The first 2 Concierge Design Principles and Service Operating Modes are included in Tier 1 scope. The third Concierge Functionality is included in Tier 2 scope Data marts and institutional reports Individual applications, such as Admissions, are delivered with a standard set of operational reports. Beyond this there will be a need for institutional reports both for internal consumption and for external agencies (Federal, State and Provincial). Although it is not part of the core project to create a complete data warehouse, Kuali Student addresses this issue by providing: 1. Data marts (which could be implemented as views or extracts that hide the complexities of the operational database) 2. Some sample reports Tier 2 scope includes the development of data marts for Tier 2 applications Tier 3 Functional Scope The following business functions are not part of the scope of the Core Program. This does not mean that these business functions are not considered to be part of the Kuali Student Service System, but rather that they will not be delivered as part of the 5 year program being sponsored by the founding institutions. These functions could possibly be implemented by Partner institutions. 1. Recruitment Application 2. Event Management 3. Housing Application 4. Athletics Application 5. Alumni Application 6. Family Financial Planning 7. Elections 8. Student Life Functionality Out of Scope of Student Service System This section provides a description of the business functions that are considered to be out of scope of a Student Services System. These are major systems requirements that institutions are expected to satisfy via another product or solution. However, application connectors to these systems may be in scope for Kuali Student. 1. Campus Calendar 2. Student Portfolio 3. Learning Management System 4. Financial Management Information System 5. Facilities Management System 6. Library System 7. Parking System Kuali Student Program Charter June 18, 2007 Page 17 of 76

18 Program Charter 3.3 Internationalization There are two key aspects to internationalization in Kuali Student. The first is that it must support any kind of curriculum and any kind of processes so that it can be implemented in any educational jurisdiction. The ability to support any kind of curriculum is achieved through the creation of Learning Unit templates that describe the characteristics of different curricula. The system will also have an infrastructure service that will allow the configuration of different institutional processes. For example, it could be configured for the Cambridge Tripos curriculum as well as the North American credit hour system. The second is multi-language support. All user facing components will be configurable to present user interfaces in any language. A data dictionary service will be used to store multilanguage elements. (Note that the Kuali Student system itself (java code, DDL, WSDLs and schemas will be delivered in English.) Multi-Language Support Kuali Student user interfaces will be connected to a data dictionary that can be configured in two ways: To support the local vernacular of each institution. For example, UBC uses the term year level for undergraduate programs, while Carnegie Mellon uses the more generic term phase ; To support different languages. As part of the core program, Kuali Student will only develop the English language dictionary. However, the underlying architecture will support other languages and Partner institutions will be encouraged to develop additional language dictionaries Multi-Currency Support Kuali Student will be developed so it can support multiple currencies. For example, a Canadian implementation would be configured to use Canadian dollars while a European implementation would be configured to use Euros. Kuali Student will also be designed to handle multiple currencies concurrently. For example, a Canadian institution could accept fee payments in both Canadian dollars and US dollars Support for International Credentials The academic history module of the Admissions Application supports tests and high-school matriculation transcripts from a variety of jurisdictions such as International Baccalaureate, British GCE, and German Abitur. Regardless of internationalization, this functionality is extremely important for North American schools that are committed to a sizeable international component in their student population Compliance with International Legislative Requirements Kuali Student will be developed to ensure it can meet basic legislative requirements in different jurisdictions. For example, the electronic funds transfer will be rules based to allow configuration to meet local needs. Another example is the tax reporting regulations. Kuali Student Program Charter June 18, 2007 Page 18 of 76

19 Program Charter 4 Technical Architecture 4.1 Guiding Principles for the Technical Architecture A set of 10 technical principles have been developed to guide the technical development of the Kuali Student system and to serve as a reference throughout the full lifecycle of the program. While these principles are open to amendments as the program progresses and as lessons are learned, every effort should be made to preserve these ten guiding principles. As a means of preserving these guiding principles, the Change Management Process will be used to amend this section of the charter and to make exceptions to the principles while building Kuali Student. The following are the ten guiding principles for Kuali Student. Service Oriented Architecture Principle 1: SOA Methodology The first characteristic of Kuali Student is that it is based on Service Oriented Architecture (SOA). Although many Java Enterprise applications are service based in that objects are accessed via service interfaces, the SOA approach is different in several respects: There is a greater emphasis on the up-front design of entities and service contracts. The artifacts of the design phase are entity models and service definitions. Services should be autonomous; they are not controlled or constrained by another service and therefore may run remotely. From a development perspective, there will be a strong presumption in favor of building services that can be deployed remotely. There will however be cases where this is impracticable for performance, security, or other reasons. Services should be loosely coupled; they are modeled and exposed through an interface that is separate from its implementation. Through loose coupling, services can be implemented in any environment as long as the implementation fulfills the service contract. There is a high degree of emphasis placed on the identification of re-useable services. An example of the benefit of SOA is the design of the authentication system for Kuali Student. By designing services (via service contracts) that are autonomous and loosely coupled it s possible to plug in any authentication system (e.g., CAS, home-grown, etc.) that implements the system s service contracts. Principle 2: Web Services The preferred implementation of the SOA is web service technology. Web services have the advantages in their simplicity, their universality, and the fact that they are platform neutral. Web services means SOAP (Simple Object Access Protocol) and WSDL (Web Kuali Student Program Charter June 18, 2007 Page 19 of 76

20 Program Charter Service Definition Language). Apache Axis is a good example of a product that implements these technologies. XML schema is the primary vehicle for expressing entity models and service contracts. In short, "XML is the platform." Principle 3: Standards Based Kuali Student will follow open standards wherever feasible. The standards observed will be in the following areas (and others where applicable): 1. The W3C Web services framework (SOAP and WSDL) 2. Kuali Student will follow WS-* standards where they apply (e.g., WS-Security, WS- Transactions, WS-Addressing, etc.). 3. Industry standards such as those supported by PESC-AACRAO 4. Java Community standards such as JSR 286 (Portlet), and JSR 94 (Rules Engine) 5. Accessibility standards 6. Internationalization standards Standards compliance is a key issue in product selection. For example, it is important that the Kuali Student Web-services engine implement the latest SOAP and WSDL standards. A product s adherence to the latest standards has the additional benefit of freeing the Kuali Student technical team from the constraint of being continuously up-to-date on every change in a standard s definition. It s understood that standards will evolve over the course of the project. While it s generally a good idea to maintain Kuali Student s adherence to the latest standards, the technical team should be prudent in its attempts to keep pace with the latest standards as doing so may have a negative impact on delivery of the product. Principle 4: Separate Governance Process for Service Contracts Service contracts are business assets of an SOA-based system, are the public definition of the system, and must be the most stable part of the system. They are governed separately and differently from that of typical development artifacts in that the governing body has representation from each service domain, the involved business units, and technical subject matter experts. This body can be decentralized where each unit is responsible for their services and those they want to make available to others, or it can be a centralized body that reviews all new, modified, or retired service contracts, or the organization can be somewhere in between. The governance body s organization will be defined during the Architectural phases of the program. The management of service contracts can be extended to external contracts as there may be cases where Kuali Student consumes stable 3 rd -party services (such as the validation of addresses by a postal service). Service contracts created by an institution (i.e., for the purpose of customization or for the consumption of external services, for example) will be maintained by the institution. Service contracts contained in the reference distribution will be maintained by Kuali Student. Kuali Student Program Charter June 18, 2007 Page 20 of 76

21 Program Charter Component Abstraction Principle 5: Abstraction of Business Processes and Business Rules Business rules and business process logic will be abstracted from the code base. Rules engines are the preferred vehicles for abstracting business rules Workflow and BPEL engines are the preferred vehicles for abstracting business process logic. The use of rules engines takes the traditional separation of business logic and presentation in an n-tier architecture one step further by externalizing business logic. Changes to business logic can be defined to the system without any programming changes. Routing logic for the workflow engine is also expressed through the rules engine. An important part of the project will involve developing interfaces for the rules engine(s). Rules engine technology also introduces the possibility of artificial intelligence in the system since one of the outputs of a rules engine can be a new set of optimized rules. The Kuali Student reference distributions will include standard templates for common business practices that may be extended by implementers to meet the particular needs of their institutions. As an example, the template calculategpa could be extended to meet the specific rules of an institution in the calculation of a student s GPA. In cases where the business process and business rules vehicles are insufficient there will be clear guidelines on how to abstract business logic in the code (as dictated by the Change Management Process). Principle 6: Abstraction of Presentation Layer and Use of an Open Source Portal Abstraction of the presentation layer allows User Interface (UI) components to be separate from the orchestration layer and the business service layer. To illustrate, a benefit of the abstraction is the ability to deliver the UI to a wide array of devices (such as PCs, cell phones, PDAs) without modification of the presentation layer s input stream to accommodate the differences in each. To help facilitate this approach, Kuali Student will be delivered through an existing portal product. Using a portal provides the opportunity to abstract the presentation layer through standards (such as JSR 286 and WSRP where there is a need for remote portlets). Portal functionality such as provisioning, customization, and personalization will remain within the domain of the portal rather than within the scope of the Kuali Student project. Principle 7: Abstraction of the Data Layer Data abstraction is implemented in three ways: Kuali Student Program Charter June 18, 2007 Page 21 of 76

22 Program Charter 1. Much of Kuali Student s data model will be derived from simple abstractions; that is, abstractions representing basic concepts and objects such as time, people, learning units, and learning results. Implementing these abstractions as identifiable domain objects (real-world objects like courses, sections, students, and instructors) is carried out through a series of configuration templates. 2. Data access will be abstracted in the data layer. The purpose is to provide database independence, allowing any ANSI SQL compliant database to be used while still allowing database-specific calls to be made within the data layer for things like performance enhancements. 3. Data access should be abstracted through an ORM framework and as a rule it will be services that provide data. Consequently, applications that need data do not need to understand the details of database navigation. Leveraging Open Source Principle 8: System Will Be Built Entirely on an Open Source Software Stack Licensing and IP Management Kuali Student will be built entirely on an open source software stack compatible with the outbound Educational Community License (ECL). Further, Kuali Student will adhere to the Kuali Foundation s IP Management Practices for inbound licensing and assessment of 3 rd -party licenses. Open Source Reference Distribution Reference distributions of Kuali Student are entirely open source. That, however, does not preclude implementers from swapping in commercial products for part of the stack. For example, an institution that has a deep investment in Oracle may wish to continue using Oracle for Kuali Student. Principle 9: Infrastructure Will Be Composed Of Existing Open Source Products Use of Open Source Infrastructure Components It is not within the scope of Kuali Student to build infrastructure components, although the technical team may need to develop web service wrappers for existing products. Kuali Student will use existing open source products for BPEL engines, an Enterprise Service Bus, Workflow and Rules Engine Technology and UI frameworks. By using a formal open source software assessment methodology, such as OpenBRR, OSSM, or QSOS, the technical team will evaluate and select software from well-established open source organizations. Involvement in Open Source Projects Because of the large scope and complex requirements of Kuali Student, and the varying stages of maturity of the various open source solutions, the technical team might become involved with the development of some of the necessary open source components. Involvement with other projects will be evaluated on a case by case basis. To help insure that Kuali Student s involvement with other open source projects doesn t Kuali Student Program Charter June 18, 2007 Page 22 of 76

23 Program Charter become an unnecessary drain on resources, involvement should be limited to very a specific purpose such as a bug fix or feature enhancement. For those cases in which Kuali Student necessarily becomes involved in open source projects that pose the risk of becoming costly and ongoing responsibilities, attempts should be made to find external organizations to provide stewardship so that Kuali Student may devolve that responsibility. Evaluation of Open Source Infrastructure Components Infrastructure developed within the Kuali foundation will be evaluated using the same criteria as any other product. Adherence to service orientation is the most important principle. However, within these constraints, Kuali Student will actively seek to leverage Kuali code, concepts, and expertise. Kuali infrastructure products will change and mature over time and therefore this is another area in which there may be a reevaluation of original choices. Development Principle 10: Java as the Language and Platform of Choice Code that is written as part of the core Kuali Student product should be written in Java and Java will be the platform of choice for Kuali Student. However, partners and other third parties can develop add-ons written in any language and that use a non-java platform as long as they can work with the Kuali Student web service framework. Above all, this means they must work with the Kuali Student service contracts. The detailed technical architecture for Kuali Student will be developed as one of the first phases of the Kuali Student Program. However, a body of initial work has already been completed as part of the planning and preparation phase of the program. This initial work is presented in Appendix C -Technical Architecture Considerations for reference. However, it should be noted that this document is incomplete and is subject to change as the technical architecture work progresses. Kuali Student Program Charter June 18, 2007 Page 23 of 76

24 Program Charter 5 Other Product Implementation Considerations 5.1 Testing Strategies In a traditional development environment, there are five distinct stages where testing takes place. Isolation testing takes place within the developer s personal workbench, although it may employ external resources such as databases and connections to production services authentication for example. Beyond this there are four conceptual stages through which a unit of work must pass. Each has different operational requirements which may be reflected in four separate operational environments through which a unit of work is promoted. DEVL (Shared Development): This is the first shared environment to which the developer submits work. Initial integration testing takes place here. Path testing and code reviews may also be done here. Stability of this instance is the common responsibility of the developers they own it although it is likely to be the most volatile. This is the first stage at which testers and evaluators get a look at new work from developers and designers. EVAL: Functional evaluation takes place here. This is a controlled, stable environment for functional correctness testing (e.g. black box testing). Some performance testing may be done here, as well as UI/UE evaluation. This instance is owned by the test/evaluation teams. VERF: Verification of operational stability, robustness, performance, etc. takes place here. This is as close to the operational environment as possible identical in every respect except that it doesn t affect end-users. (e.g. it employs a private copy of the production database.) PROD: Production. This is an active instance of the reference distribution of all packages. In the Kuali Student project, this will be the Test Drive public instance of the service. Our goal is to ensure that the production instance contains only code that has gone through appropriate QA processes. At the same time, we want to expose pre-production code to a wide range of testers and evaluators. A detailed Testing Strategy will be developed as part of the Technical Architecture phase of the project. 5.2 Quality Assurance Reviews Throughout the duration of the Kuali Student Program, Quality Assurance (QA) reviews will be conducted on a regular basis. A QA review conducted by an unbiased party can assist the program team by providing a second opinion on the progress towards achieving the program goals. Listed below are the identified types of QA review and the approach to be taken for these reviews Project Management Practices In this case, the objective of the review is to ensure that effective project management practices are being followed. Some of the aspects to be investigated include: governance structures, effective decision making, project control (scope, schedule, and budget), project status reporting and communications, risk management practices. These reviews will focus on the execution of the Kuali Student Program plans and will be conducted after the first 6 months and then every 12 months there after. Kuali Student Program Charter June 18, 2007 Page 24 of 76

25 Program Charter Architectural Reviews A Service Oriented Architecture implemented using Web Services is a relatively new technology set. The Kuali Student Program will experience a medium to high risk due to newness and lack of experience with these technologies. To mitigate this risk, it will be important to build in Architectural QA reviews during the early phases of the project. These reviews will be conducted by bringing in industry experts from commercial vendors such as IBM and Sun Microsystems who have some experience building systems with these technologies. These industry experts will conduct a review and assessment of the proposed architecture. Subsequent architectural reviews can be expected during the later stages of the project since it is expected that the available technologies will advance during the course of the 5 year program. Carefully considered changes to the architecture may benefit the system Code Reviews Throughout the duration of the project, we will need to integrate code from a number of external sources. We may find that there is existing code among the Founders that meets our functional requirements, and that only needs minor re-factoring to meet our SOA standards. Likewise, there may be other existing code from non-founders that could easily be adapted. We need a formal mechanism for reviewing these code contributions to ensure that they meet our defined standards, including: Standards compliance (see Appendix C Technical Architecture Considerations for a full discussion on standards) o SOA standards o Development standards, including thorough documentation and legibility/comprehensibility of code o Security standards o Accessibility standards Overall fit with our technical architecture License compliance Functional requirements Usability standards These thorough code reviews will also be necessary for any new code that the Founders develop as part of the Kuali Student Program, as well as any code submitted by our partners. For partner-contributed code, we should follow the same process we used for selecting initial code contributions from Founders and other external sources. Standards Compliance A fundamental success criteria for Service Oriented Architectures, is the adherence to published standards. These standards include such areas as XML Schema, WSDL first design, development/coding standards, 3 rd party software licensing, accessibility, etc. If published standards are not followed, the future flexibility and agility of the system may be compromised. As a result, Kuali Student will require structured design and code reviews to be performed. These reviews will be conducted for both the Kuali Student Program and for any Partner Program that intends to deliver software for the Kuali Student Service System. The review must be completed prior to acceptance of the software into the general software release. Completeness of Testing In order to ensure that the software developed will meet the defined business requirements, Kuali Student will define a comprehensive Testing Strategy that is intended for use by all Development nodes within the program. Quality Assurance reviews will be conducted to ensure that all projects and development nodes are following the Testing Kuali Student Program Charter June 18, 2007 Page 25 of 76

26 Program Charter Strategy, have developed thorough and complete test plans, and are executing the test plans effectively. The Testing QA reviews will be accomplished by assigning a QA Manager to work with the Testing Coordinators as they proceed through the test process. Usability Testing Part of the vision for Kuali Student is to develop software that is person centric and easy and intuitive to use. The design of the User Interface is a key factor in achieving this vision. Templates or style guides will be created to ensure the interface is consistent across all software modules and to ensure the specific transactions are easy to navigate through. QA reviews will be conducted to ensure adherence to the published style guides (similar to the Standards reviews) as well as to ensure the usability of the software. These reviews will be accomplished by assigning a User Interface (UI) expert to work with the software designers at the earliest stages of development. The UI expert will also work with the Testing Coordinators to test usability and resolve issues at the development stage. 5.3 License Management A key part of the vision for Kuali Student is the concept of community source development. The community source model will allow universities and colleges to leverage their system development resources, to share the results of their work with other institutions, and to take advantage of work done by others. The community source model increases return on investment, and provides a formal, tested, framework to support the traditions of sharing and cooperation which are an important part of the higher education world. The Kuali Foundation uses various licenses to distribute software and documentation, to accept regular contributions from individuals and organizations, and to accept larger grants of existing software products. These licenses, and the Kuali Foundation Intellectual Property (IP) management practice, help to achieve the goal of providing reliable and long-lived software products through collaborative open source software development. In all cases, contributors retain full rights to use their original contributions for any other purpose outside of Kuali while providing the Foundation the right to distribute and build upon their work within Kuali. Kuali Student, as part of the Kuali Foundation, will use the Educational Community License V2.0. The Educational Community License (ECL V2.0) consists of a set of copyright licensing terms that may be found at The ECL was certified by the Open Source Initiative in June of (See Appendix D for a description of the ECL text.) The Kuali Foundation believes that open-open licensing is fundamental to achieving the goals of the Kuali Community. The ECL is open-open because it permits unrestricted, use, modification, and distribution without a copyleft provision to require downstream modification to carry the same terms. The ECL is fundamental to achieving the goals of the Kuali Foundation and supportive of collaborative development across both nonprofit and commercial organizations. A full description of the Kuali Foundation Intellectual Property Management Practices can be found at: Product Documentation The Kuali Student Program will develop and publish several documentation artifacts relating to the design and development of the Software product. A complete list of documentation Kuali Student Program Charter June 18, 2007 Page 26 of 76

27 Program Charter deliverables will be developed during the Application and Technical Architecture phases, but it will include such documents as: Technical Architecture Plan Entity Relationship diagrams Service Definitions (including Class Diagrams and Sequence Diagrams) Service Contract definitions XML Schema definitions Software development standards Installation Guides System configuration and implementation guides Etc. The objective of this documentation is to provide sufficient information to enable the efficient implementation, product support, enhancement and future development of the product by the Kuali Student community. Because of the ability of Kuali Student to be configured to support very different business processes and business logic, it is not feasible for the Kuali Student Program to provide documentation relating to specific institutional implementations such as business process diagrams, workflow diagrams, end user guides, training manuals, and on-line help aids. This type of documentation will be radically different depending on how the institution chooses to configure their system. It is expected that each institution will develop this type of documentation as part of their implementation process. However, the founding institutions will commit to publishing their implementation documentation to be used as templates for other institutions to start from. It is hoped that as the number of institutions that have implemented Kuali Student grows, the community source model will support the development of a body of knowledge and re-usable implementation materials that can be shared with others. 5.5 Implementation Support The scope of this charter includes the development of the Kuali Student Software (the Software ) and the activities leading up to the development of the Software. However, the founding institutions will be implementing the first Software releases at their institutions at the same time the Kuali Student Program team is developing later Software releases. Each institution will have very different issues with regard to implementation and bridging to in-house systems. It will be impossible for the Kuali Student Program team to track and control the various different implementation issues with all of their associated governance concerns. It is therefore outside the scope of this charter to plan for the implementation of Kuali Student at any institution. It is expected that each institution will prepare a separate implementation plan and project charter to govern its own implementation of Kuali Student. The founding institutions may choose to have their implementation teams working in parallel with the Kuali Student Program team. In this case, individuals who are working part-time on the Kuali Student Program may possibly have time to participate on an institution implementation team provided that it does not detract from their responsibilities on the Kuali Student Program team. In fact, there may be some synergies if the implementation team can assist with testing Kuali Student Program Charter June 18, 2007 Page 27 of 76

28 Program Charter the Software. However, resource allocations and team responsibilities must be clearly defined in these cases to avoid conflicts of interest. Other institutions may choose to have their implementation teams wait until development of a Software release is complete before starting up their implementation project. In this latter case, there will most likely be a clearer distinction between the Kuali Student Program team and the implementation team. However, there will still be areas of overlap and common interest. Again, the responsibilities of individuals who are allocated to both teams will need to be clear in order to avoid confusion and conflict of interest. It is outside the scope of the Kuali Student Program to develop detailed end user guides or training manuals for Kuali Student. Only system installation, basic implementation plans and configuration instructions will be prepared. A detailed list of these deliverables will be prepared during Phase 2 of the project Software Architecture. It is envisioned that materials developed by early institutional implementation teams will be made available back to the community to assist with future implementations. This is one of the desired outcomes and benefits of community source software development. Materials that may be shared include: Detailed implementation work plans Configuration templates Training guides and materials End user documentation or on-line help Another avenue that will be encouraged is the development of commercial vendors to assist with implementation. This will be an important support avenue for smaller institutions that do not have a large in-house IT department to assist with implementation. 5.6 Product Support and Community Sustainment The Kuali Student Service System Board is not in a position to warranty the software that is developed through this program. (The Educational Community License will contain warranty disclaimers.) It will rely on the community of developers (including the Founders and other implementers) to provide product support and enhancements for Kuali Student. For the longer term, the Kuali Student Board recognizes three conditions that will be essential to the success of Kuali Student: 1. Creating a community of adopters. The board must engage in efforts to build a community of adopters that will install the software at their institutions and will pass the knowledge and practices gained in doing so back into the community knowledge base. A community needs trained developers who can contribute to the open source base with fixes and extensions to Kuali Student. 2. Sustaining a community of adopters. The board must plan for long term sustainability in the Kuali community and for Kuali Student itself. Without an effective method of sustained support the promise of an alternative to current software choices will be short lived. Because it will be very difficult for the Founding institutions to provide substantive implementation and ongoing support to adopter institutions, it is vital that a healthy vendor ecosystem with multiple sustainable services vendors be encouraged. Kuali Student Program Charter June 18, 2007 Page 28 of 76

29 Program Charter 3. Establishing procedures for on-going product maintenance and enhancements. The Kuali Student Board will be concerned with putting together a product support organization to respond to product issues and enhancement requests. Because the underlying technical architecture is based on service-orientation and Web Services, it is essential that this support organization has well defined procedures and is well positioned to ensure that the published development standards are followed. Because the Kuali Student Program team must remain focused on the development and delivery of the Software for the duration of the Program, the support organization will need to be in place when the first of the founding institutions start their implementation projects. The Kuali Student Board will work with the Kuali Foundation to define an organization with well defined release management procedures and a priority setting process for central product support. Initial characteristics for this organization include: The support organization will need to have at least 1 full time staff member to perform the support coordination activities. Detailed release management and support procedures will need to be defined during the architectural phase in the first year of the program. All Kuali Student implementers will need to pay fees for this product release management and to receive the product fixes. The board will explore setting up this organization within the Kuali Foundation, possibly funded through Kuali Foundation fees. Commercial vendors will be encouraged to participate and hopefully will be engaged early enough so that they are in a position to provide implementation services, product support and enhancements from very early on. Commercial vendors or community Partners may also wish to offer hosted solutions using the Kuali Student System. If these models make sense to the community, the board will work to support them. If commercial vendors cannot be encouraged to provide services, the founding institutions and other adopting institutions will have to rely on their own implementation teams to resolve product issues and work with the support organization and its procedures for product enhancements. All institutions implementing the software, whether they be a founder, a partner or an adopter; will be encouraged to contribute to the on-going enhancement and maintenance program. The product development team will need to allocate time and effort to ensure that product support issues are resolved and integrated into subsequent product development. Kuali Student Program Charter June 18, 2007 Page 29 of 76

30 Program Charter 6 Program Delivery This section outlines the approach and/or methodology that will be used to guide the progress of the program. It should be a well organized approach that will lead the program from the start to a successful completion. 6.1 Phased Approach The Kuali Student Program is large and complex. There is a risk that team members will not be able to work effectively and efficiently and that they will lose sight of what they are trying to accomplish. A structured approach that is easily understood by all stakeholders is essential to ensure program success. This section will discuss the phased approach. Concepts include: Well defined phases of approximately 4-6 months each Clear definition of deliverables at each stage Phase deliverables should be tangible assets. In case of failure of the entire project, there is still value gained and useable deliverables for the investment Ownership of deliverables is clearly defined QA reviews and checkpoints at the end of each phase. Sign off of phase deliverables as complete At the end of each phase, the plans for the next phase will be updated based on the new information available. The plans will remain flexible and are modified to meet the realities of the day 6.2 Service Oriented Architecture Critical Success Factors The methodology chosen to design and build Kuali Student must be one that ensures the critical success factors for a Service-Oriented Architecture are in place. It is therefore important to have a complete understanding of these factors. The following list outlines the critical success factors for a service-oriented architecture: Ensure all stakeholders in the project understand and accept service-orientation. Provide training for developers and other stakeholders. Commitment to an initial business analysis phase (process models and entity models) to clearly define what will be developed. This will require that the conceptual design be abstracted into a new concept of rules driven design versus the previous model of building each requirement separately. This investment is essential to achieve the vision of extending the functionality and meeting the needs of the next generation student system. Investment in service modeling and service contract design. There is a need to find the balance between the up front investment in service analysis and the natural desire for early deliverables. The cost of insufficient service analysis is a significant risk of decreased system agility, decreased reusability, and increased data transformation requirements. All of these contribute to decreased service contract longevity and increased cost of redevelopment. Agile Development versus SOA. Although full Agile Development cannot happen until the service analysis and service contract designs are complete, many of the agile development techniques can be applied throughout the program. These techniques can be very effective, allowing the team to focus on delivering software that meets each institution s needs with the highest possible quality, in the least possible time, and at the lowest possible cost. Using these techniques may require training for some developers. Kuali Student Program Charter June 18, 2007 Page 30 of 76

31 Program Charter Skill sets SOA requires new skill sets. Business analysts with proven skills to perform process, entity and service modeling must be combined with the technical skills to design the service contracts. It may be difficult to find individuals who possess both skill sets. In this case, the business analysts must work very closely with the technical designers. Strict adherence to standards: standardized XML schema, development standards, WSDL first design, etc. A well defined and structured methodology and approach is essential to completing the program deliverables according to the program schedules. Deliverables and delivery dates will need to be clearly defined with clear responsibility for delivery assigned. Sponsorship and program governance will also need to be clearly defined with active, visible support. 6.3 Project Team Training All parties should be familiar with service-orientation. This includes business stakeholders as well as application managers and software developers. When any one of these parties is left out of the loop, there is a major risk of misunderstanding and subsequently, poor decision making. For example, traditionally-educated designers who only know about object-orientation may be inclined to couple services too tightly to the actual functions. (A quote from An SOA Case Study: Agility in Practice) Training on the SOA methodology and service-orientation is a critical success factor for SOA projects. We will use the following approach to ensure sufficient and consistent training across all of the development teams: Kuali Student Kick Start - Introductory training to ensure all resources participating on the project have a solid understanding of the Kuali Student vision, the program charter, and the operational procedures. This training package will evolve over time as new standards are developed, but will include such things as: o Program Charter Overview including appendices o Application Development methodology overview (high level) o Technical Architecture approach overview or Technical Architecture Framework (depending on stage of program) o Collaboration tools o Development Standards o Project management disciplines status reporting, change requests, issue management. o Licensing management for Developers o SOA Critical Success Factors Service Oriented Analysis and Design a 3-5 day workshop or training session directed at business analysts, lead subject matter experts, and senior technical staff. This course should include such things as: o SOA overview o Application Development Methodology (Detailed) o Modeling techniques o Overview of documentation templates o Training on modeling tools o Model conventions and standards Kuali Student Program Charter June 18, 2007 Page 31 of 76

32 Program Charter Service Oriented Architecture and Web Services This training will be directed at senior technologists, senior developers and developers. It will be custom tailored according to the needs of the individual and the project. It will be composed of a series of recommended training courses as well as custom training prepared for the team. It could include such things as: o SOA Basics o Web Services Basics o Magic Draw training o Other product training 6.4 Modular Delivery In order to balance the natural tension between early software releases and the need to invest in up front analysis, the software will be released in phases. This will also reduce the risk by defining smaller manageable pieces. In addition, software releases may be assigned to different development nodes. Software will be packaged according to application bundles that make sense to the business. The release schedule cannot be defined until the application architecture and the domain partitioning has been completed, however, the founding institutions have partitioned the functionality according to their agreed development priorities. Tier 1 functionality includes the core modules that are critical and fundamental components of a student system. Tier 2 functionality includes modules that are important for a fully functioning student system, but they have a lower priority for development or they may have large components that can be satisfied by an existing best of breed software product. These development tiers are fully defined in Appendix B Detailed Functional Scope. 6.5 Program Phases This section describes each of the phases or steps in the program plan. It will describe the purpose of the phase and give an overview of what is to be achieved. It is intended to be a high level summary of activities. The reader should refer to Appendix E (Technical Architecture Deliverables an Approach) and Appendix F (Application Development Approach) for a full description of the development methodology and deliverables. Detailed work plans will be prepared for the architectural phases (first 3 phases) of the project. Detailed work plans for later phases of the program will be developed after the early phases are complete. Before each phase begins, the work plans will be reviewed and adjusted based on the knowledge gained from previous phases. Kuali Student Program Charter June 18, 2007 Page 32 of 76

33 Program Charter Kuali Student Phased Modular Approach Functional Gate Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Program Management &Communications (Users & IT Functional) Technical (IT Architects & Developers) Jul 2007 Application Architecture - Business Requirements Technical Architecture - Process models -Technology proofs -ER models -SOA standards Nov High Level Service Models Dec 2007 Development Infrastructure Service Modeling R1 - Developers workbench (Infrastructure and - Procedures Cur. Dev.) - Standards Apr 2008 May 2008 Develop Configuration Contract Design R1 Application (Infrastructure & Domain 1) - Configuration Infrastructure -Proof of concept Pilot Sep 2008 Oct 2008 Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure and Cur. Dev.) Contract Design R2 (Domain 2) Mar 2009 Apr 2009 Release 1 & Implement Test May 2009 Jun 2009 Re-plan / Re-Architect / Implement & Transition to Support July Preparation and Planning Phase The purpose of this Step is to provide the initial planning and preparation for the program. Key activities include: Preparation of the program charter Definition of the program methodology and approach Identification and commitment of program investors Preparation of proposal to Mellon Foundation Detailed planning and specific resource commitment for early phases of the program Application Architecture Phase The purpose of the Application Architecture phase is to discover all the cross-cutting services within the student domain. We need to understand the connections and dependencies between the services in order to achieve our goals of service modularity and re-use. We also need to gather sufficient information to effectively partition the full student domain into sub-domains that can be worked on incrementally. Modeling (or diagramming) tools and techniques are used to document the system requirements so that they can be easily verified with the user community. These diagrams provide a consistent and efficient method to communicate across institutions either the Kuali Student Program Charter June 18, 2007 Page 33 of 76

34 Program Charter Founders building the system or Adopters that may implement the system. In addition, the diagrams are used as inputs to the application architecture and design work that must be completed by the application development team. In this phase the high level business requirements are documented and a model of the Application Architecture is created. The following figure outlines the proposed major activities Service Modeling Phase The purpose of the Service Modeling phase is to refine the list of Service Candidates and clearly define what the service does - what data it manipulates, what operations it performs and what messages it processes. However, during the Service Modeling phase, the definitions of the services are fluid they change frequently as more and more information is gathered. In order to avoid a lot of re-work, the information that is gathered is maintained at a medium level of detail. The service definitions that result from this phase will be used as inputs to the Service Contract Design Phase. Once the team moves on to the Service contract design phase, which involves a great deal of very detailed and specific work, it is important that the service definitions do not shift dramatically. For this reason a user signoff checkpoint is placed at the end of this phase. The following figure outlines the proposed major activities. Kuali Student Program Charter June 18, 2007 Page 34 of 76

35 Program Charter Service Contract Design Phase The purpose of the Service Contract Design phase is to take the list of Service Definitions and further refine them by clearly defining how the service does its work. Complete technical specifications for the Service Contract are defined. The service contract specifications that result from this phase will be published to the community and may be used by a very wide audience. It is hoped that the community will use these service contract specifications to develop student system functionality beyond the scope of this program that will enhance the total Kuali Student product offering. As a result, the information that is gathered and used to create the contract specifications is very detailed. It is important that there be very little change to the service contract specifications after they are published. The following diagram outlines the proposed major activities. The text following the diagram provides a description of these activities and describes the deliverables produced. Kuali Student Program Charter June 18, 2007 Page 35 of 76

36 Program Charter Technical Architecture Phase During this phase of the Technical Architecture, the technology team will select a stack of open source web products that can be assembled to form a Service Oriented Architecture. These products will be integrated into a trivial hello world application in order to demonstrate that they can work together. Kuali Student Program Charter June 18, 2007 Page 36 of 76

37 Program Charter Development Infrastructure Phase This part of the technical architecture project establishes the tools and procedures required for product development. It will create an integrated developer s workbench, complete with module stereotypes, procedures for use, and installed development infrastructure. Kuali Student Program Charter June 18, 2007 Page 37 of 76

38 Program Charter Develop Configuration Application Phase A key deliverable of the Technical Architecture is the creation of a Proof of Concept application. This involves creating an integrated prototype that will exercise every part of the technology stack including (but not limited to): o A working instance of the portal (with sign-on and provisioning) o Code that illustrates all the module stereotypes o An application that demonstrates the flexibility of the technology stack to be configured to meet the requirements of multiple institutions: o The data configuration functionality o The rules engine o The workflow engine (service orchestration) o The authorization service The proof of concept application will be a fragment of an application from the functional design, most likely from the Curriculum Development Application regarding Learning Units. The point is not to explore the business design but to exercise every part of the technology stack. In order to demonstrate this application fragment or proof of concept, the system Configuration Application must first be developed. The Configuration Application is itself a set of services that will be built upon the Service Oriented Architecture. Kuali Student Program Charter June 18, 2007 Page 38 of 76

39 Program Charter This phase of the Technical Architecture will develop the Configuration Application, demonstrate the SOA architecture and prove its ability to be used as a platform to develop the Kuali Student Service System. Kuali Student Program Charter June 18, 2007 Page 39 of 76

40 Program Charter Software Design and Development The purpose of the Software Design & Development phase is to finalize the design and development of the Kuali Student application or domain currently under construction (Curriculum Development for Release 1). This includes the development of all services, user interface components, and system documentation required to release the product. It also includes the configuration of the reference implementation including the data abstractions, the business logic rules, and the orchestrated services that will form the end-to-end business process. The Kuali Student Program will use Agile Development techniques during the software development and design phase. Agile development techniques will allow us to focus on delivering software that meets each institution s needs with the highest possible quality, in the least possible time, and at the lowest possible cost. Agile development techniques involves a series of iterative and incremental design and development cycles, each one time boxed to achieve a specific deliverable. Members of the user community will be active participants on the development teams, providing valuable input into the planning, design, and testing of the system. The planning, analysis and design will take place throughout the projects to ensure that development will be able to adapt to changes in requirements and/or scope. Frequent feedback loops and test driven development will ensure that a high level of quality is maintained throughout the development of the system. The unique nature of the Kuali Student will rely heavily on the agile concept of Learn, Try, Reflect and Adapt to ensure the ongoing success of this project. The application developers will be organized into 2 work streams for the design and development phase. One will focus on the User Interface (UI) or user facing components and the other will focus on the development of the Services. Although these two teams must work closely together, this division of work will remove the temptation to hard-wire the UI to the services. The following figure outlines the proposed major activities during the Design and Development phase. The text following the figure provides a description of these activities and describes the deliverables produced. Kuali Student Program Charter June 18, 2007 Page 40 of 76

41 Program Charter Program Management & Communication These activities are conducted throughout the life of the program. They include the following: Program management, governance and reporting Risk management Prepare Communications Strategy and Plans Execution of communication plans o External community of Adopters marketing and building the community o Internal communities within the founding institutions Building support organization o Governance structure and priority setting o Procedures for incorporating fixes and enhancements back into the product o Resources, fees & subscriptions Building the vendor community to provide services and support and possibly product integrations Licensing compliance and IP management Accounting and Reporting Kuali Student Program Charter June 18, 2007 Page 41 of 76

42 Program Charter Product Release & Implementation Support During this phase of the program, the Kuali Student Software will be packaged up and released for implementation. Product support will be provided by the Kuali Student developers to the founding institutions who are implementing the software at the time of release (at least one). At the same time, the Kuali Student developers will work with the long term sustainment organization (possibly a vendor) to transition the support activities to that organization. After the release of the first Kuali Student Software, the program team will be positioned to undertake multiple parallel development streams. Based on the learning, experience, and standards developed during the first release, the development nodes should be able to operate with more autonomy. The project team organization will shift to the second structure (if this hasn t already happened). Subsequent releases will contain packages of code developed by different nodes. The release schedules and scope of the releases will be determined during the planning phase at the end of Release Deliverables and Milestones This section outlines the specific deliverables that will be created at each phase of the program. Deliverables are tangible and measurable assets, not activities. Project Phase Milestone Planning & Preparation Result: Deliverable or Tangible Asset Created Investors identified and Memorandum of Understanding (MOU s) signed Program Charter completed and approved by the Board of Directors Proposal to Mellon completed Specific resource assignments made and project team for second phase committed Detailed project plan prepared and reviewed with all team members Program Kick-Off completed with all team members having reviewed and understood the Program Charter Application Architecture For the full scope of the Kuali Student Program the following communication tools will be used to describe and document the Kuali Student Program Charter June 18, 2007 Page 42 of 76

43 Program Charter Project Phase Milestone Result: Deliverable or Tangible Asset Created application architecture: ER Diagrams & Descriptions Business Process Models Swim Lane Diagrams Use Cases including specific test cases for reference implementation Institutional Gap Analysis Service Stack Diagram Service Definition Document for service candidates Service X-reference Diagram (partition diagram) to partition the services into applications QA Review and Signoff Service Modeling For the scope of the specific release, the following deliverables will be produced: Extended Use Cases Service Description Document Object Models Service X-reference Diagram (partition diagram) Service Interaction Diagram User Interface Style Templates (design specifications) QA Review and Signoff Service Contract Design For the scope of the specific release, the following deliverables will be produced: Detailed Use Cases Contract Design Specification JUnit Tests WSDL Java interface Service Registry Proof of Concept Tests (see Develop Configuration Application) Re-usable UI Components QA Review and Signoff Technical Architecture Sandbox development workbench A working set of infrastructure components: portal, Kuali Student Program Charter June 18, 2007 Page 43 of 76

44 Program Charter Project Phase Milestone Result: Deliverable or Tangible Asset Created rules engine, workflow engine, BPEL engine, service bus, service registry, authentication service, authorization service, web service engine A list of deficiencies and proposed fixes Developer training sessions completed Hello World execution of the servlet QA Review and signoff Development Infrastructure A Kuali Eclipse programmer workbench Workbench documentation Workbench tutorials Coding and naming standards UI component stereotypes and developers manual Web services stereotypes and developers manual Web services framework with orchestrated services and a developers manual Infrastructure design document with operational procedures Installed and functional product development landscape Registered URLs, namespaces, directory structures and documented migration procedures QA Review and signoff Development Configuration Application Services coded, tested, and documented for the Configuration Application Data dictionary service Search service Rules definition service Workflow service Authorization service Working technology proof illustrating a thin slice of the Curriculum Development Application QA Review and Signoff Kuali Student Program Charter June 18, 2007 Page 44 of 76

45 Program Charter Project Phase Milestone Software Design and Development Result: Deliverable or Tangible Asset Created For the scope of the specific release, the following deliverables will be produced: Screen layouts and screen navigation Class diagrams Sequence diagrams Database design Use cases & test cases Service Orchestration Design JSPs/HTML/CSS/JS Portlets/Servlets Java objects.jar files.ddl scripts.aar file The reference implementation configured for reference test cases and data Install guides System overview documentation Basic implementation and configuration guides QA Review and Signoff Product Release & Implementation Support For the scope of the specific release, the following deliverables will be produced: Software Release package available for download Kuali Student Test Drive in production Kuali Student certified Service Contracts published Procedures for incorporating software contributions published At least one founding institution live in production with the released Kuali Student modules. Transition product knowledge to support organization Updated project plans, architecture and developers workbench QA Review and Signoff Kuali Student Program Charter June 18, 2007 Page 45 of 76

46 Program Charter 6.7 Program Timeline A summary of the program phases and a high level timeline is presented below. Project Phase Program Management & Comm Planning and Preparation R1 Application Architecture R1 Technical Architecture R1 Development Infrastructure Develop Configuration Appl. Service Modeling R1 Service Contract Design R1 Software Design and Devl R1 Release and Impl Support R1 Update Plans R2 Update Architect and Infra R2 Service Modeling R2 Service Contract Design R2 Software Design and Devl R2 Release and Impl Support R2 Update Plans R3 Update Architect and Infra R3 Service Modeling R3 Service Contract Design R3 Software Design and Devl R3 Release and Impl Support R3 Update Plans R4 Update Architect and Infra R4 Service Modeling R4 Service Contract Design R4 Software Design and Devl R4 Release and Impl Support R4 Q1/07 Q2/07 Q3/07 Q4/07 Q1/08 Q2/08 Q3/08 Q4/08 Q1/09 Q2/09 Q3/09 Q4/09 Q1/10 Q2/10 Q3/10 Q4/10 Q1/11 Q2/11 Q3/11 Q4/11 Q1/12 Q2/12 Kuali Student Program Charter June 18, 2007 Page 46 of 76

47 Program Charter 7 Program Organization This section describes how the program will be governed the committees to be put in place, the reporting relationships and the roles and responsibilities of the key project team members. 7.1 Partnerships This section describes the current partners in Kuali Student and describes their level of commitment. While the Kuali Student Program may start with the partnerships as described below, it is anticipated that these partners may change over time. Five years is a long time and many things can change in that time period. It is proposed that there be a partnership review after the first year of the program (after architectural work is completed) and then again after the second major software release in year 3. 1 year checkpoint after Architecture Phase 3 year checkpoint after Release 2 5 year checkpoint after Release 4 Invest in Architecture Phase Invest for 2 years Develop Tier 1 functionality Year 1 Gate If decide not to proceed, tangible assets can be used for in-house development If partnerships fail take code inhouse and continue with development assets not lost Build Community of Adopters Year 3 Gate Invest for 2 years Develop Tier 2 functionality with Partners Assess if additional partners are needed to participate in development of remaining functionality If community fails take code inhouse and continue with development assets not lost Year 5 Gate At end of year 5 move to community sustainment model adopters help fund the on-going enhancements After each review, the Kuali Student Board will assess whether additional new Founders or Partners are required to continue development. In this case, the proposed commitment or investment would be reviewed by the existing Founders according to the following process: Review existing on-going commitment of current Founders Review proposed commitment from new Founders Review updated resource requirements, project timelines and costs to assess the current situation. Kuali Student Program Charter June 18, 2007 Page 47 of 76

48 Program Charter Ensure vision and objectives of all Founders remain aligned Any decision to add new Founders requires unanimous approval by all Founder Board members. If an existing Founder wishes to terminate their commitment rather than staying for the entire length of the project, the following process will be followed: The departing Founder will provide 6 months written notice to the Board. This is not an event that is expected or planned, but must be accommodated if circumstances dictate. It is expected that all deliverables for the current phase be completed or acceptable arrangements made for the handover process. New Partners may be accepted at any time. The following process will be used to review potential Partners: Review proposed investment that Partner would like to make Ensure the vision and objectives of the Partner are aligned with the overall vision and objectives of the Program. This is particularly important when considering development proposals. All Partners who wish to provide developers or code to the project must agree to follow the published Kuali Student development standards for SOA. Requires unanimous approval by all Founder Board members Founders Founders are able to make a significant commitment to the program including the following: Contribute a minimum of $1,000,000 per year, in cash and/or qualified staff resources, for the 5 year period of July 2007 June Align with the vision of Kuali Student as described in this Charter document Sign a Memorandum of Understanding that outlines their specific commitment to the Program (required by Mellon Foundation). Sign off on this program charter to indicate their full agreement with the vision, objectives, scope, approach, deliverables and priorities Adhere to the governance structure, decision-making processes, and project management disciplines, including the service oriented analysis methodology as described in this program charter Commit to run some or all modules of the core product in production within 1 year of being released. Agree to be an active advocate for the Program, including executive level communications to the community. Designate two senior representatives for the Program Board that will direct program resources. Use the Educational Community License V2.0 for all work products created by the core members. Develop appropriate local expertise in Service Oriented Architecture and other technical tools. The Founders for the Kuali Student Program include: The University of British Columbia; The University of Maryland, College Park; The University of California, Berkeley; Florida State University; and San Joaquin Delta College. A detailed description of each of these institutions with their specific goals and objectives can be found in Appendix G. Kuali Student Program Charter June 18, 2007 Page 48 of 76

49 Program Charter Partners Partners are institutions that are unable to make the level of commitment required to be a Founder, but they are committed to the program and are able to make the following specific commitments: Align with the vision of Kuali Student as laid out in the Kuali Student Program Charter Contribute resources, in the form of cash and/or staff, toward the development of Kuali Student. The development resources may be allocated to core system scope undertaken by the Founders or may be allocated to modules complementary to the core system scope. May commit to implementing one or more Kuali Student modules (core or non-core) in production. Participation on either the Technical or Functional Steering Committees attend scheduled meetings. Participate in workshops to ensure the Kuali Student System meets the needs of the broadest possible community Use of the Educational Community License for all work products created by the core. Act as an advocate for the Program. The Partners for the Kuali Student Program include: The Massachusetts Institute of Technology and Carnegie Mellon University. A detailed description of each of these institutions with their specific goals and objectives can be found in Appendix G Adopters Adopters are institutions that have expressed an interest in implementing 1 or more modules of Kuali Student once the software has been developed and released. Adopters are essential to the success of the program through their advocacy and support for the program and the resulting growth in the community of developers Other Partnerships and Stakeholders Organization AACRAO American Association of Collegiate Registrars and Admissions Officers Description of Commitment Lend their name in support of the program to help develop the community of adopters. Visible support from AACRAO shows there is business commitment for the project it is not just an IT project Provide a communication channel for Kuali Student to engage the North American community o Conference presentations o Newsletters o Websites o Distribute surveys Survey their community to determine broad interest in certain system requirements Mellon Foundation Potential financial investment Will provide the Binding energy to get things going Provide a connection to other projects of this nature. We can learn from their experiences Kuali Student Program Charter June 18, 2007 Page 49 of 76

50 Program Charter Kuali Foundation Allow use of the Kuali brand Provide a mechanism for code distribution and copyright by providing licensing procedures and agreements Offer one or more seats on the Kuali Foundation board Provide a mechanism for long term sustainability of Kuali Student through collection of membership fees and provision of a software release management structure Provide an avenue for commercial engagement Provide access to common project infrastructure that may be leveraged or shared by Kuali projects including such things as Wiki tools, issue management tools, collaboration tools, code management tools, legal advice, accounting mechanisms, etc. Provide a public website where Kuali Student can publish information on the program and the software Provide an accounting mechanism for managing contribution funds if required Provide access to Kuali Foundation architectural resources to enable sharing of technical information and strategies Kuali Student Program Charter June 18, 2007 Page 50 of 76

51 Program Charter 7.2 Program Team Organization The following diagram outlines the project structure that will be used to manage and govern the Kuali Student Program during the Architectural phase (the first months). It is not intended that the diagram represent all of the paths of communication, but rather illustrates the key reporting relationships. Kuali Student Service System Team Organization Architectural Phase Kuali Student Board CIOs* Registrars* Extended Board AACRAO Mellon Foundation Kuali Foundation Partner Institutions *Functional Steering Committee *Technical Steering Committee Program Director General Institutional Resources ** QA Manager Configuration Manager UI Expert Documentation Coordinator Project Analyst/Admin Program Communications Development Infrastructure Systems Infrastructure DBA Security Services / Application Architect / (Project Manager) Business Lead Subject Analysts Matter Experts* Subject Matter Experts* Chief Technical Architect / (Project Manager) Technologists (or Lead Developers)* * Representation from each Founding Institution ** May be consulted from time to time during Architectural Phase Kuali Student Program Charter June 18, 2007 Page 51 of 76

52 Program Charter As the project moves from the Architectural phase to the Development Phase, the organization structure will need to change to accommodate the additional resources and complexities involved with remote development teams. The following diagram outlines the organization structure that will be put in place at that time. Some of the characteristics of the team compositions are noted below: Functional team subject matter experts (SMEs) would always have representation from all Founding institutions and possibly from other institutions as well in order to get the best possible definition of the business requirements from a wide variety of institutions The structure of the development teams may vary according to the specific project deliverable. Some teams may have cross representation from all Founders and others may have developers from just one institution. The specifics of the team composition will be defined during the Architectural phase of the project. Kuali Student Service System Team Organization Development Phase Kuali Student Board CIOs* Registrars* Extended Board AACRAO Mellon Foundation Kuali Foundation Partner Institutions *Functional Steering Committee *Technical Steering Committee Program Director Program Wide Resources Chief Technical Architect Services Architect QA Manager Configuration Manager UI Expert Program Communications Documentation Coordinator Project Analyst/Admin Project Manager Module Teams Lead Subject Lead Matter Expert Developer Business Testing Analyst Coordinator Development Node Resources Development Infrastructure Systems Infrastructure DBA Security Subject Matter Experts* Testers* Developers Kuali Student Program Charter June 18, 2007 Page 52 of 76

53 Program Charter 7.3 Roles & Responsibilities This section provides a detailed description of the roles, the responsibilities and the resource assignments for the project. Name Project Role Responsibility 2 from each Founding Institution - one from IT - one from registrars office Ted Dodds (Chair) Brian Silzer Jeff Huskamp William McLean Shelton Waggener Susie Castillo- Robson Larry Conrad John Barnhill Lee Belarmino Chris Coppola At least one from each founding institution Audrey Lindsay (Chair) Bill Spann Susie Castillo- Robson Rick Burnette Catherine Mooney Jo-Anne Stevenson Board Members Institution UBC UBC UMCP UMCP UC-B UC-B FSU FSU SJDC SJDC Functional Steering Committee Institution UBC UMCP UCB FSU SJDC MIT Sets the vision & strategic direction for the program Approves the program charter and ensures that the deliverables from the program will support the broader vision and the specific business requirements Overall responsibility to champion the solution to be delivered by the program and to support the program objectives within their university and across the community Communicates the vision, strategic direction & organizational commitment to all levels of the university Communicates status & opportunities to senior management within their institutions Ensures that local impediments or conflicts at their institution are addressed in a timely manner. Approves all plans and budgets Ensures high level university needs are met Ensures plans are carried out and budgets are met Represents diverse community interests Holds regular review meetings to monitor the progress of the program Provides direction and actively supports the project Approves the program charter and organization structure Provides direction for scope, budget, plans and key deliverables that impact the overall program direction Approves key strategy documents Recommends priorities for development of key application modules Serves as a decision making body to ensure that all decisions made are consistent with the goals and objectives of the program Makes decisions in a timely manner (as required or requested through escalation procedures) in order to avoid impacting program schedules Empowers program team members to make business process design decisions Approval body for all major scope and specification change requests that impact the program schedule, budget and/or resulting business solution Escalates all issues that cannot be resolved by the committee to the Board members for vote and final decision Holds regular review meetings to monitor the progress of the program (budget, schedule, activities, risks). Acts as a communicator/ motivator/ marketer, Kuali Student Program Charter June 18, 2007 Page 53 of 76

54 Name Project Role Responsibility Kuali Student Service System Program Charter communicating and promoting project objectives throughout the founding institution Acts as the stakeholders representatives Obtains understanding of, and helps mitigate, key program risks 1 to 2 members from each institution Leo Fernig (Chair) Dave Alderson JR Schulden Jeff Bauer Chris Kirschenman Scott Thorne Martha Baron Cath Fairlie Technical Steering Committee Institution UBC UMCP UCB FSU SJDC MIT CMU Program Director Provides direction with regard to technical architectural issues and actively supports the project Provides input to the program charter and approves the Technical Architecture sections Provides direction for technical architecture, infrastructure, technical scope and other key technical deliverables that impact the overall program direction Approves key technical strategy documents Recommends priorities for development of key infrastructure modules such as identity, workflow, rules engines, etc. Serves as a decision making body to ensure that all technical decisions made are consistent with the goals and objectives of the program Makes decisions in a timely manner (as required or requested through escalation procedures) in order to avoid impacting program schedules Empowers program team members to make technical design decisions Sets development standards, especially those related to SOA and Web Services implementation Approval body for all major technical change requests that impact the program schedule, budget and/or resulting solution such as changes to development tools or changes to architectural components Escalates all issues that cannot be resolved by the committee to the Board members for vote and final decision Holds regular review meetings to monitor the progress of technical program deliverables Acts as a communicator/ motivator/ marketer, communicating and promoting project objectives throughout the founding institution Obtains understanding of, and helps mitigate, key program risks, with an emphasis on technical risks Overall responsibility for ensuring that the program is delivered as defined in the Program Charter Ensures that project management processes for controlling scope, schedule, budget, risk, quality, and resources are well defined and are followed Keeps the lines of communication open among all program participants, the Kuali Student board, Key Stakeholders and the community Maintains high level oversight of the schedule, budget and Kuali Student Program Charter June 18, 2007 Page 54 of 76

55 Name Project Role Responsibility Kuali Student Service System Program Charter 1 for each Project Segment or Development Node TBD Leo Fernig the delivery of all expected deliverables Prepares reports to the Board (Gantt charts, activity reports, budget updates, issues lists, risk assessments and key deliverables) and seeks approval when required Identifies, quantifies and communicates outstanding issues, project risks and discrepancies and submits recommendations to resolve issues and mitigate risks Maintains ongoing contact with the Board, the Project Managers, and the Steering Committees and keeps all advised of the status of work being done by the program team Ensures that sign-offs and approvals are obtained in a timely manner Project Manager Overall responsibility for ensuring that the deliverables for the Development Node are delivered on-time, on budget Ensures that project management processes for controlling scope, schedule, budget, risk, quality, and resources are followed Maintains overall control of the schedule (person-days), budget and the delivery of all expected deliverables Prepares the management deliverables (Gantt charts, activity reports, budget updates, issues lists, risk assessments and key deliverables) and seeks approval when required from the Functional Committee and the Technical Committee Identifies, quantifies and communicates outstanding issues, project risks and discrepancies and submits recommendations to resolve issues and mitigate risks Maintains ongoing contact with the Program Director and the Steering Committees and keeps it notified of the status of work being done by the project team Ensures that sign-offs and approvals are obtained in a timely manner Keeps the lines of communication open among all project Chief Technical Architect participants Overall responsibility for ensuring that the technical deliverables for the Architectural Phase are delivered ontime, on budget Ensures that project management processes for controlling scope, schedule, budget, risk, quality, and resources are followed Prepares the management deliverables (Gantt charts, activity reports, budget updates, issues lists, risk assessments) and seeks approval when required from the Functional Committee and the Board Chairs the Technical committee Responsible for delivering a reference implementation of the technical architecture Responsible for creating a reference development environment including developers toolkit, coding Kuali Student Program Charter June 18, 2007 Page 55 of 76

56 Name Project Role Responsibility Kuali Student Service System Program Charter To be determined Services Architect standards, migration standards, and database management policies and standards During later phases of the project, responsible for coordinating the practical application of the technical architecture across all development projects, working closely with the Services Architect, the DBAs, the release manager and the QA manager Identifies, quantifies and communicates outstanding issues, project risks and discrepancies and submits recommendations to resolve issues and mitigate risks Responsible for investigation, impact assessment, and resolution of change requests arising from the application of the technical architecture Maintains ongoing contact with the Program Director and the Functional Committee and keeps them notified of the status of work being done by the technical teams Ensures that sign-offs and approvals are obtained in a timely manner Keeps the lines of communication open among all project participants Overall responsibility for ensuring that the deliverables for the Application Architecture, Service Modeling and Service Design Phases are delivered on-time, on budget Ensures that project management processes for controlling scope, schedule, budget, risk, quality, and resources are followed Prepares the management deliverables (Gantt charts, activity reports, budget updates, issues lists, risk assessments) and seeks approval when required from the Functional Committee, the Technical Committee and the Board Responsible for developing the application architecture, identifying all services, service integration points, and the application partition diagrams Responsible for ensuring the application development methodology is followed and is applied consistently across all locations and development nodes. During later phases of the project, responsible for coordinating the practical application of the application architecture across all development projects, working closely with the Chief Technical Architect, the DBAs, the release manager and the QA manager Identifies, quantifies and communicates outstanding issues, project risks and discrepancies and submits recommendations to resolve issues and mitigate risks Responsible for investigation, impact assessment, and resolution of change requests to the application architecture arising from software design and development Maintains ongoing contact with the Program Director, the Functional Committee and the Technical Committee; keeping them notified of the status of work being done by Kuali Student Program Charter June 18, 2007 Page 56 of 76

57 Name Project Role Responsibility Kuali Student Service System Program Charter the service modeling/design teams Ensures that sign-offs and approvals are obtained in a timely manner Keeps the lines of communication open among all project participants Participates on the Functional and Technical steering committees as required QA Manager Responsible for ensuring the overall quality of the program deliverables Responsible for ensuring that the published SOA design and development standards are followed, both by Founder development teams, Partner development teams, and commercial development teams Responsible for ensuring license management strategy is followed Conducts IP reviews to ensure compliance Conducts quality reviews of deliverables including design documents, service contracts, software programs, etc. Responsible for defining testing strategies and procedures and ensuring that these processes are followed by all development teams (testing coordinators) Reviews all test plans prepared by development teams (testing coordinators) to ensure their completeness Configuration Manager User Interface Expert Responsible for creating, managing and running the project build files Maintains the repository for the code base (for example subversion) and implements branching policies Coordinates the alignment of code base versions Works with the Lead DBA to coordinate alignment of database versions Ensures that all project teams are working on the same version of the base products (for example Java 1.5 etc.) Responsible for the development of style templates and usability guidelines for Kuali Student. These templates and guidelines will be developed in consultation with the functional committee, the technical committee, and the FLUID project by ATRC Involved in the design and development of re-usable interface components such as widgets, skins, etc. Involved at the design stage of software to ensure that the developed software addresses usability and accessibility concerns Ensures that all developed software meet internationalization standards and accessibility standards Ensure that style templates are applied in a uniform manner across all development nodes and within partner projects Coordinates usability testing with the usability lab Business Analysts Facilitate workshops to establish current and future business requirements for Kuali Student Kuali Student Program Charter June 18, 2007 Page 57 of 76

58 Name Project Role Responsibility Kuali Student Service System Program Charter Lead Subject Matter Expert Area Subject Matter Experts Works with the SMEs to model the business requirements using Entity Relationship diagrams, Process Flow diagrams, and Service Modeling diagrams Prepares data analysis Works closely with the Development team to translate the business requirements into service candidates and service contracts, liaising with the design and development of the Kuali Student solution Assists the SMEs in the preparation of test scripts Ensures that all necessary checks and balances are in place for adequate control, balancing, and audit requirements Assists with definition and implementation of system security requirements Key participant in workshops to establish current and future business requirements for Kuali Student Works with the Business Analyst, providing input to model the business requirements using Entity Relationship diagrams, Process Flow diagrams, and Service Modeling diagrams Assists with data analysis Provide input to the project team on both institutional and community perspectives in consultation with these groups. Works closely with the Development team to develop the Kuali Student solution. Develops communications plans and business awareness to assist in the development of community support for the initiative Communicates project status and progress back to the user community Prepares test scripts & participates in all test cycles Accepts and sign-off all project deliverables for the business area that they represent Assists with definition and implementation of system security requirements Available for consultation on a part-time basis Attends workshops and provide expertise in a specific area of the business Recommends the appropriate business process and assist in the formulation of, or change in business practices based on SSS vision for the future Brings a strong understanding of the requirements for their business area Provides input to the project team on both institutional and broader community perspectives in consultation with these groups. Committed to the quality of the solution Assists in preparation of test scripts & participates in test cycles as required May accept and sign-off all project deliverables for the business area that they represent Kuali Student Program Charter June 18, 2007 Page 58 of 76

59 Name Project Role Responsibility Testing Coordinator Kuali Student Service System Program Charter Prepares test plans and detailed test cases that cover all use cases Works with the QA manager to ensure test approach follows the standards defined for the project. Coordinates the testing efforts Works with the developers to resolve issues identified during the testing process Works with the usability expert to follow up on usability issues Testers Executes test cases and document results Re-tests after fixes have been applied Program Communications Project Analyst/ Administrator Documentation Coordinator Prepares key communications deliverables such as the Stakeholder Analysis, and the Communications Plan for the Kuali Student Program Develops communication vehicles including: o External program website o Presentations o Newsletters or articles o Posters o exhibits o events Provides administrative support Budgets tracking and reporting Distributes and updates Project plans Tracks Licenses Etc. Ensures all documentation is complete and accurate Maintains the documentation libraries Prepares documentation packages as required for releases Lead Developer Works closely with business analysts and subject matter experts to ensure a clear understanding of the business requirements Designs, Codes, and Tests software Prepares program documentation Works with testers to resolve issues May oversee and direct the work of other developers Developers Designs, Codes, and Tests software Prepares program documentation Works with testers to resolve issues DBAs, Systems Infrastructure, Security Works closely with the technical team to provide input to the SOA architecture Works with the technical team to develop standards, procedures and policies as the architecture is defined Provides operational support for the underlying development infrastructure Kuali Student Program Charter June 18, 2007 Page 59 of 76

60 Program Charter 7.4 Recruitment for Positions The success of the program will depend to a large extent on the individuals filling key positions. Each founding institution will be making resources available to fill positions on the program. A clear process is needed to ensure that each position is filled with the best possible resource that has the skills required to perform the position responsibilities. The following process will be used to recruit and fill the program positions: Founders to submit resumes of candidates for each position: Key positions will be decided by the Board o Lead Technical Architect o Lead Services Architect o Functional Committee o Technical Committee o QA Manager o Configuration Manager Discussion and recommendation If required, vote The following process will be followed if it is determined that a team member is not able to meet the requirements of their position: Performance issues should be brought to the attention of the Program Director and the Functional or Technical Steering Committee member of the institution the team member resides at. These 2-3 individuals will work to try to resolve the issue. If it cannot be resolved, a recommendation will be made to the Board and the relevant Board member will take action as required. Kuali Student Program Charter June 18, 2007 Page 60 of 76

61 Program Charter 8 Program Costs & Benefits 8.1 Benefits The benefits of adopting and implementing a community source student system such as Kuali Student may include: The software is created specifically for higher education with its unique needs already understood and built into the product. Shared resources spread the cost of product development over many universities instead of multiple universities paying the same cost for the same system. This is especially true during the software development phase of the project. We estimate that this savings is on the order of 15% 30%. These savings are somewhat offset by the cost to implement the system within the institution (giving the lower number in the range). When the source code is open, there are continuous upgrades and enhancements contributed by the community of adopters which lowers the cost of software maintenance and enhancement in the future. It is estimated that these savings may be on the order of 40 50%. Flexibility of the proposed SOA architecture allows implementers of the Kuali Student software to use a combination of Kuali Student modules, vendor supplied components and home grown modules. This approach will minimize the disruption involved in moving the institution to the next generation system. The benefits of participating as a Founder in the Kuali Student Program include: The stimulation, interaction and exchange of ideas will generate a better product than each institution could develop on their own. This benefit includes both the sharing of technical concepts and ideas as well as the sharing of business processes and procedures. Participation as a Founder in the Kuali Student Program will enable the institution to provide input to the direction and priorities for the program. Founding institutions should get close to a custom solution. The Founders will gain a large degree of knowledge transfer regarding the application and the supporting infrastructure through their participation in the program. Implementation of the Kuali Student software will be faster and less expensive for the Founders since they have already gained an understanding and knowledge about the application being implemented. Work that Founders do on the infrastructure and architecture for Kuali Student can be used to drive the architectural vision throughout the institution, beyond the student system. Founders will have the satisfaction and recognition of having contributed to the higher educational community. Commitments made to other Founders and investors (such as Mellon) will provide the motivation to move forward expeditiously with the system development and implementation. Kuali Student Program Charter June 18, 2007 Page 61 of 76

62 Program Charter 8.2 Costing Assumptions The following planning assumptions were used when calculating the program costs: Standard costing has been used to calculate the value of the staff resources. Salary costs are fully loaded costs and include base salary, benefits and an allocation for overhead (PCs, facilities, training, etc.). The standard salary costs were derived by taking an average of the salary costs for the 4 founding institutions where the majority of the resources will be located (UBC, FSU, UMCP, UC-B). For specific roles where the FTE count is 1 (such as the program director), close to actual salary costs have been used rather than average costs. Since the US and Canadian dollars are very close in value, costs are calculated in generic dollars with no adjustments for currency conversion. Part-time resources such as board members, steering committee members and part time Subject Matter Experts (SMEs) are not included in the cost of the program. Full time staff, whether functional (SME) or technical are included in the cost projections. Part-time technical staff that play a significant sustained role in the project are included in the costs. Program wide costs that are not specific to any one institutions are listed under program costs Program costs (full time resources) are calculated starting April 1, In general, the annual numbers are calculated from July 1 to June 30, however the first year costs are calculated from April 1 June 30 (a period of 15 months) 8.3 Costs Summary A summary of the total program costs and the total staff resources is provided below. Detailed costing sheets, which outline the details of resource allocation and cost calculations by institution, are provided in Appendix H. 8.4 Funding Contributions The table below outlines the costs and the sources of funding for the program. Specific details of the institutional contributions and the program level contributions are provided in Appendix H. The following assumptions have been made regarding the funding model: The $3,000,000 program contingency (10% of total program funds) will not be funded until it is required. Founders and partners understand that these funds will have to be identified should the need arise. Funding from sources such as the Mellon Foundation and CANARIE (Canada s Advanced Internet development organization) cannot be confirmed until the proposals have been submitted and approved. Funding shortfalls will need to be address by either identifying new sources of funds (additional Founders or Partners) or by reducing program costs The following cost categories will need to be carefully managed to ensure highest value for lowest costs: o Project team training o Consulting Expertise o Training materials o Hardware and other tools Kuali Student Program Charter June 18, 2007 Page 62 of 76

63 Program Charter Kuali Student Program 5 Year Costing and Funding Estimates Y1 FTE Months Y1 to June 2008 Y2 to June2009 Y3 to June 2010 Y4 to June 2011 Year 3 Year 1 Resource Cost Year 2 Resource Cost Resource Cost Y2 FTE Months Y3 FTE Month s Y4 FTE Month s Year 4 Resource Cost Y5 FTE Month Y5 to June 2012 s Year 5 Resource Cost 5 Year Total Costs Total FTE Months Total Resource Cost Program Costs Staff/Resource Costs (Labour) $4,952, $5,335, $5,761, $5,752, $5,382, $27,184,062 Travel & Accomodation $577,500 $515,000 $522,500 $510,000 $510,000 $2,635,000 Hardware - Development Environment $80,000 $80,000 $80,000 $80,000 $80,000 $400,000 Software Licenses $40,000 $40,000 $40,000 $40,000 $40,000 $200,000 Project Team Training $40,000 $40,000 $40,000 $40,000 $40,000 $200,000 Training Materials $80,000 $80,000 $80,000 $80,000 $80,000 $400,000 Consulting Expertise $128,000 $128,000 $128,000 $128,000 $128,000 $640,000 Other (Meals, Meetings, Misc.) $53,000 $53,000 $53,000 $53,000 $53,000 $265,000 Contingency $600,000 $600,000 $600,000 $600,000 $600,000 $3,000,000 Total Program Costs $6,550,616 $6,871,829 $7,305,100 $7,283,300 $6,913,217 $34,924,062 Staff Contribution by Institution University of British Columbia 96.0 $872, $949, $1,176, $1,185, $1,062, $5,246,717 University of Maryland, College Park $895, $887, $922, $922, $861, $4,489,583 University of California, Berkeley $882, $1,015, $964, $964, $873, $4,699,417 Florida State University $886, $1,045, $1,112, $1,086, $991, $5,121,583 San Joaquin Delta College 28.0 $244, $344, $336, $336, $336, $1,596,500 Massachusetts Institute of Technology 30.0 $274, $0 0.0 $0 0.0 $0 0.0 $ $274,300 Carnegie Mellon University 18.0 $154, $11, $0 0.0 $0 0.0 $ $165,500 Total Staff Contribution $4,208, $4,254, $4,512, $4,494, $4,124, $21,593,600 Cash Contributions University of British Columbia $135,000 $147,500 $160,000 $147,500 $147,500 $737,500 University of Maryland, College Park $106,000 $106,000 $106,000 $106,000 $106,000 $530,000 University of California, Berkeley $110,000 $80,000 $80,000 $80,000 $80,000 $430,000 Florida State University $97,500 $97,500 $97,500 $97,500 $97,500 $487,500 San Joaquin Delta College $252,000 $252,000 $252,000 $252,000 $252,000 $1,260,000 Massachusetts Institute of Technology $30,000 $0 $0 $0 $0 $30,000 Carnegie Mellon University $20,000 $5,000 $0 $0 $0 $25,000 Andrew W. Mellon Foundation Request $500,000 $1,000,000 $1,000,000 $0 $0 $2,500,000 CANARIE Request $250,000 $250,000 $0 $0 $0 $500,000 Other $0 $0 $0 $0 $0 $0 Other $0 $0 $0 $0 $0 $0 Total Cash Contributions $1,500,500 $1,938,000 $1,695,500 $683,000 $683,000 $6,500,000 Total Contributions $5,708,950 $6,192,267 $6,207,967 $5,177,250 $4,807,167 $28,093,600 Funding Shortfall -$841,666 -$679,563 -$1,097,133 -$2,106,050 -$2,106,050 -$6,830,462 Kuali Student Program Charter June 18, 2007 Page 63 of 76

64 Program Charter 9 Project Management This section outlines the mechanics of how the program and the associated projects will be managed. It is critical that project team members clearly understand how they will complete their activities and how they will report their progress. 9.1 Project Planning Project plans are critical to providing the required framework from which to control the program and ultimately facilitate its successful outcome. It is critical that the plans are well understood by all project team members and stakeholders. A high level overview of the program plan is presented in Section 6.0. Detailed work plans have been prepared for the architectural phases of the project (first 15 months of work). Detailed work plans for later phases of the program will be developed after the architectural work is complete. Before each phase begins, the work plans will be reviewed and adjusted based on the knowledge gained from previous phases. The purpose of the planning function is to: Define the project activities in sufficient detail to understand the time and resource requirements and to manage the progress Provide a roadmap to achieving the project objectives Form a baseline to evaluate project progress and success The Kuali Student Program will use activity-based project plans. Once approved, the plans will be the baseline for all reporting purposes. Activities within the project work plans should have the following characteristics: Each sub-team will develop a detailed project plan for their area of responsibility. Activities are the basis for defining work and tracking progress Activities should be worded in such a way that it is evident what the resource will actually be doing An activity should not be longer than 5 days in duration in most cases. Each activity has a planned start date, planned end date, estimated effort in days, task dependencies, assigned resources, and a documented percent complete. For reporting purposes, team members will update the percentage of completion for each activity rather than actual hours spent on each activity. MS Project will be the tool used to create and maintain the work plan The component plans will be combined by the Project Analyst into a high-level master program plan which will form the basis for all program level reporting. Once approved, this program plan will be the baseline plan for all plan versus actual reporting purposes. The milestone dates of the program plan cannot be changed without the approval of the Kuali Student Board and the Program Director. Kuali Student Program Charter June 18, 2007 Page 64 of 76

65 Program Charter 9.2 Status Reporting Status reporting is an essential component of program management and control. It is an effective mechanism for communications within the program and to associated projects. The table below outlines the proposed status reporting schedule. Interested Party Kuali Student Board Description of Communication: What, Who, When, How The board conducts its business and project oversight via bi-weekly or monthly conference calls or video conference calls. The frequency of meetings will be adjusted depending on the program needs at the time. The board will work with and administratively through the Functional Steering Committee, the Technical Steering Committee, and the Program Director. The Program Director will prepare a weekly status report based on project status reporting. The program status report will be distributed to the Board Members prior to the weekly call The Board will meet in person on a quarterly basis. The Program Director and optionally the Chairs of the Functional and Technical Steering Committees will also attend to provide updates on the program status: Percent completed on planned activities Planned / Actual/ Variance reporting on project costs Upcoming project activities Highlights of any project issues or escalation points Risk Report and Forecast Special meetings of the Board may be called if there is a significant issue that requires immediate resolution Extended Board This reporting includes organizations who have made an investment in the Kuali Student Service System and who may be interested in a weekly status update. For example the Mellon Foundation, principle Partners, potentially commercial vendors, and AACRAO These organizations will receive a copy of the weekly report prepared by the Program Director Quarterly or semi-annual Partners meetings will be held to provide more detailed information and program overviews to these partners. Functional Steering Committee The Functional Steering Committee will receive a copy of the weekly status report prepared by the Program Director The Functional Steering Committee will meet in person (or via video conference) on a monthly basis to review deliverables and issues relating to the functional scope of the program. Discussions and decisions will include such things as: o business requirements o scoping and priorities o process design o scheduling and implementation issues Kuali Student Program Charter June 18, 2007 Page 65 of 76

66 Program Charter Technical Steering Committee Program Director and Project Managers o risk assessment and forecast The Functional Steering Committee will report non contentious decisions and conclusions to the Program Director and the Project Managers The Functional Steering Committee may escalate issues to the Board for vote and resolution after providing and summary analysis and recommendations The Technical Steering Committee will receive a copy of the weekly status report prepared by the Program Director The Technical Steering Committee will meet in person (or via video conference) on a monthly basis to review deliverables and issues relating to the technical architecture of the program. Discussions and decisions will include such things as: o definition of development standards SOA and Web Services o reference implementation of technical architecture o development environment developers toolkit o practical application of the technical architecture o scheduling and implementation issues o risk assessment and forecast The Technical Steering Committee will report non contentious decisions and conclusions to the Program Director and the Project Managers The Technical Steering Committee may escalate issues to the Board for vote and resolution after providing and summary analysis and recommendations The project managers will convene a weekly video conference to report progress to the Program Director The Project Managers will prepare a weekly status report to update the Program Director on: o status against plan o work accomplished during the past week o work scheduled for the next week o status of outstanding business or technical issues o risk assessment and forecast Project Teams Individual project teams will hold weekly status meetings Team members will update the project manager on: o status against plan o work accomplished during the past week o work scheduled for the next week o status of outstanding business or technical issues o risk assessment and forecast The project manager will provide a weekly status report in the standard format to the Program Director. This will enable the Program director to complete the status reports for the Board. Kuali Student Program Charter June 18, 2007 Page 66 of 76

67 Program Charter 9.3 Change Request and Issue Management The tools the Program Director will use to control scope are the Program Charter, Change Request procedure and Issue Management procedure. The Program Charter specifies the original agreement for project execution between the Program Team and the Program Board. Change can be defined as anything that affects the program execution with regard to functional scope, technical architecture, schedule, resources, cost, or project organization. Change Requests are created to document any change to this baseline charter and are tracked using the Change Request Log. Issues are interactions that impede project or program progress. There are a number of reporting layers within the Kuali Student Program. These layers can be depicted as follows: Program Board Program Director Escalation Process Functional Technical Steering Steering Committee Committee Project Managers Escalation Process Project Team Members Each layer in the escalation process provides the Program Board with the controls necessary to keep the program on time, within budget and meeting the specified business requirements. Each layer also shares the following objectives: To maintain awareness of project progress To evaluate progress in terms of cost, quality and timing To cause adjustments to the project plans in response to issues that cannot be resolved at a lower level in the escalation process The escalation process must ensure that change requests and business issues are resolved within 2 business days of a recommendation being brought forward. Every effort will be made to resolve issues and change requests at the lowest level of the organization structure. The program team has been structured to ensure the members have the authority and ability to make effective decisions as well as timely access to decision makers as required. However, there will be cases where conflicts arise and decisions must be escalated to a higher level. Any decision or issue that cannot be resolved within 2 business days will be immediately raised to the next level of the escalation structure Change Request Procedure Changes may be classified as either Project level changes or Program level changes. Kuali Student Program Charter June 18, 2007 Page 67 of 76

68 Program Charter Project level changes are changes to the scope or plans of a sub-project of the program and will impact only that project. For example project level changes might include: Change to the functionality or design within a specific application module Change to the technical design of a specific service contract Change to a member of a project team The Change Request Procedure for a project level change is outlined below: 1. A team member identifies the need for a change. 2. The member fills out the Change Request form, first describing the proposed change and then enumerating the reasons for it. The Change Request is submitted to the relevant Project Manager and is logged in the Change Request Log. 3. The Project Manager analyses the request and may solicit input from either the Program Director or one of the Program Steering Committees. 4. If the Project Manager gives preliminary approval, the request is investigated by an assigned party to perform an impact analysis. The impact analysis must consider how the change will affect the scope of the project, the budget, the schedule, the resources, and the costs. The analysis must also review the available options, evaluate the risks and benefits, and make recommendations on a proposed course of action. 5. Following the investigation, the Project Manager will review the Change Request and make a decision. If appropriate the Change Request will be escalated to the Program Director or one of the Program Steering Committees for a decision. 6. The Project Manager will designate the Change Request as approved, closed, deferred, or rejected. The decision rational will be documented on the Change Request for future reference. 7. If a change is approved for implementation the work required to make the change will be incorporated into the program charter and associated project plans. Program level changes are changes to the fundamental principles laid out in this charter and will have a significant impact to the entire program. For example Program level changes might include: Increase in Program scope to include a new application module Change in the priority for development of the application modules Change in a standard development tool, or 3 rd party software used to develop the software Change in the software version of a component of the software architecture such as the version of the database Change in a release date Change in a key member of the program team Addition or termination of a Founder or Partner The Change Request Procedure for a Program level change is outlined below: 1. A team member identifies the need for a change. 2. The member fills out the Change Request form, first describing the proposed change and then enumerating the reasons for it. The Change Request is submitted to the Program Director and is logged in the Change Request Log. Kuali Student Program Charter June 18, 2007 Page 68 of 76

69 Program Charter 3. The Program Director analyses the request and solicits input from members of one of the Program Steering Committees. If it is a functional change the Functional Steering Committee will participate. If it is a technical change, the Technical Steering Committee will participate. 4. If the Program Director and the appropriate Functional or Technical Steering Committee give preliminary approval, the request is investigated by an assigned party to perform an impact analysis. The impact analysis must consider how the change will affect the scope of the project, the budget, the schedule, the resources, and the costs. The analysis must also review the available options, evaluate the risks and benefits, and make recommendations on a proposed course of action. 5. Following the investigation, the Program Director will convene the Steering Committee to review the Change Request and make a decision. If appropriate the Change Request will be escalated to the Program Board for a decision. 6. The Program Board, the Steering Committee or the Program Director will designate the Change Request as approved, closed, deferred, or rejected. The decision rational will be documented on the Change Request for future reference. 7. If a change is approved for implementation the work required to make the change will be incorporated into the program charter and associated project plans Issues Management Procedure A project issue can be defined as: A problem with 3 rd party software that the development team is dependant on. This may be commercial or open source software (eg. Oracle, mysql, AXIS, etc.); An item that impedes project or program progress; Lack of cooperation (fit) of a team member; An item that is a point of debate or controversy, or An item that is for future implementation consideration that requires formal resolution by the Project Manager, the Program Director, one of the Steering Committees or the Board. Issues must be identified, resolved, and documented in a timely fashion in order that the project may move ahead. Proper issue management must provide a clear audit trail of all issues and decision resolutions. All issues on the Kuali Student Program will be managed through a formal issue management process and will be recorded in the Issues Log. The Issues Log will also be used for documenting future enhancement opportunities. Specific tools for tracking issues will be identified during the architecture phase of the project, but currently JIRA is considered to be the primary tool. Issues raised and entered in the Issues Log by the originator, will be reviewed by the Project Manager and assigned to an individual responsible for analysis. Solution alternatives will be identified, analyzed and a recommendation made. The Project Manager will review the analysis and make a decision. All issue resolutions must be documented prior to the close of the issue. Kuali Student Program Charter June 18, 2007 Page 69 of 76

70 Program Charter If necessary, significant issues will be escalated to the Program Director, one of the Steering Committees or the Program Board for resolution. The Project Managers and the Program Director will monitor the Issue Log to ensure that issues are resolved in a timely manner. 9.4 Weekly Time Reporting Labour costs are one of the largest factors in the cost of the project. Tight control over these costs is essential to maintain control over project expenditures. The following time reporting mechanisms will be used to control this aspect of the program: Timesheets for all contractors will be prepared on a weekly basis and submitted to the Project Manager. Timesheets are due first thing Monday mornings. Timesheets will NOT be required for internal resources 9.5 Project Documentation Strategy Specific documentation formats will be prepared for each of the project written deliverables. Although some project team members may see this as a negative constraint on their creativity, the benefits of consistent documentation formats include: More efficient development since the structure is already provided. No time is wasted by all team members striving to find a good structure Consistency of documentation across all teams will result in document recognition which will facilitate inter-team communication Increase in quality since all documents will be consistent and complete Project team members will be provided with a package of templates to use. All team members must follow the documentation formats provided when completing project reporting. Project status and control templates will include the following: Status Reports Issue Log and Issue Resolution forms Change Request Log and Change Request forms Technical documentation templates are provided in Appendix F Application Development Approach. They include such things as: Business Process models Entity Relationship diagrams Swim Lane diagrams Service Descriptions Service X-Reference Object model Service Interaction diagrams Service Contract specifications Service Registry Template 9.6 Collaboration Tools Effective communication and collaboration is a critical success factor in any project, but it is particularly important within a distributed project with remote development nodes. While the program will try to minimize travel requirements due to cost and personal impacts, some travel will be required to ensure the success of the program and to ensure that communication paths remain open. Kuali Student Program Charter June 18, 2007 Page 70 of 76

71 Program Charter It is anticipated that travel requirements during the early stages of the program (Application Architecture and Technical Architecture) will be greater. As the program moves into the development phases, it is anticipated that the development nodes will be more independent and therefore travel requirements will be reduced. It is essential that the Kuali Student Program have effective tools to support collaboration efforts. The following tools will be used to support remote collaboration efforts: o Video and audio conferencing through bridge technologies o Adobe Connect net meeting product o Confluence Wiki for sharing materials o JIRA bug tracking and issue tracking Kuali Student Program Charter June 18, 2007 Page 71 of 76

72 Program Charter 10 External Communication Approach The Kuali Student Program communication will have two focuses. Internal communication within the Program will focus on successful execution and delivery of the program. This type of communication is discussed in detail in Section 9.2 (Status Reporting) of this Charter. External communication to the community will focus on developing the community of Adopters and Partners. The communication program will be an essential part of developing the community and ensuring the long term success of Kuali Student. The communication program will have 2 key deliverables: the Stakeholder Analysis and the Communication Plan. The Stakeholder Analysis examines the groups that may be directly and indirectly impacted by the program. The Communication Plan lists messages to be delivered in each campaign, the audience, the channel, the timing, the message creator, and the sender. It is a tactical document and is continually updated to meet the evolving needs of the project. Communication is the responsibility of all team members. The detailed Stakeholder Analysis and Communications Plans will be developed during the Architecture Phase of the Project. An example of these two documents is provided in Appendix I for reference. Kuali Student Program Charter June 18, 2007 Page 72 of 76

73 Program Charter 11 Risk Management Project Risk Management includes identifying, analyzing, and responding to project risk. The intent is to minimize the consequences of adverse events, which may prevent the project from meeting its objectives. A key element of risk management is to identify the highest-priority risks and to keep attention focused on them as the project evolves over time. Risk management is a dynamic and proactive process that requires continuous vigilance. The Risk Assessment Report quantifies risk based on a Risk Index. The Risk Index is derived by multiplying the severity of the risk impact, high (3), medium (2), low (1), times the probability of the risk occurring, high (3), medium (2), low (1). For example, a potential risk that is assigned a high severity (3) with a moderate probability of that risk occurring (2) would produce a risk index of 6. The detailed Risk Assessment Report prepared during the Planning and Preparation phase of the program is presented in Appendix J. This report will be reviewed and updated on a monthly basis, by the Program Director working with the Project Steering Committees, to ensure that risk items and response plans are adequately being addressed. The report will track planned versus actual risk mitigation activities and forecast the risk index for each risk area to determine if the mitigation activities are successful. It will also identify any new risk areas that may arise during the course of the program execution. Risk assessment and forecasting will become part of the regular weekly status reporting. A summary of the most significant risks identified for the program is presented below. (See Appendix J for a complete list.) Overall, the Kuali Student Program is judged to have a risk index of 6 (Med High). Ref. # Risk Item Description And Potential Consequence or Impact 1. Failure of the partnership of Founding institutions. misunderstanding of the goals and objectives of the program cannot agree to schedule of deliverables and priorities, cannot agree on standards or business requirements breakdown of governance model 2. Size, scope, and complexity of the project are all very large. Requires multiple development teams, working remotely. Deliverables not well understood Teams not working efficiently Communication breaks down between remote sites Remote development teams don t follow standards resulting in product that doesn t integrate well. Overall project will take more resources from each institution or the time lines must be extended beyond the anticipated 5 years Kuali Student Program Charter June 18, 2007 Page 73 of 76

74 Program Charter Ref. # Risk Item Description And Potential Consequence or Impact 3. Technology Risk: A Service Oriented Architecture implemented using Web Services is a relatively new technology set. Lack of experience within the founding institutions and within the industry for these technologies. Design mistakes leading to significant problems at the development stage Design and development take longer than expected as problems are worked out Costs increase 4. Business Analysis Risk: Project team members are inexperienced with the concepts and guidelines of Service Orientation. Service modeling and service design skills not available. Methodology is new and not well understood. Results in services that are too tightly coupled and a reduction in flexibility in the system Don t realize the expected benefits of service composition or development agility 5. Developer Change Management: Service Oriented Analysis requires an investment in up front business models (process diagrams, entity diagrams), service modeling, and service contract design before design and development of the software can get started. This approach is contrary to the agile development methods that have been adopted by the developer community over the last few years and active resistance may be encountered. This is a big change management issue. Developers don t follow the SOA methodology Don t realize the expected benefits of service composition or development agility Software modules due no integrate well 6. Lack of appropriate skills or resources at founding institutions or partner sites(e.g. business analysis skills) Forced to hire contractor resources which adds to cost of the program Alternatively, conduct intensive training for the team members which adds cost, takes time and has a learning curve quality of the deliverables is compromised 7. Service Oriented Architectures (SOA) requires an upfront investment in service analysis and service contract design to be successful. First software releases are not available for an extended period of time Product takes longer than planned to deliver Community looses confidence in project and adoption rate not realized. Executive from founding institutions loose confidence resulting in pressure to withdraw from the program 8. Pressure for early delivery of software (within founding institutions or from Mellon) result in a shortened Service Modeling process. Deliverables from service modeling are compromised Don t realize the expected benefits of service composition or development agility Product costs more to deliver and maintain in the long run 9. Standards Risk: A fundamental requirement for a successful SOA is the adherence to standards. Standards may not be followed, particularly by remote development teams or partners Don t realize the expected benefits of service composition or development agility Software modules do not integrate well 10. Proposal to Mellon Foundation is not successful or partially funded founding institutions will need to fund all aspects of the project May need to add another Founder or commercial investor Kuali Student Program Charter June 18, 2007 Page 74 of 76

75 Program Charter Ref. # Risk Item Description And Potential Consequence or Impact 11. Partner or Adopter communities do not develop as anticipated No institutions other than the Founders chose to implement the software Difficult (time consuming) for founding institutions to implement the developed modules Commercial vendors not available to support other institutions A community of developers to support and enhance the software does not develop Founders are required to fully support, enhance, and maintain the software for the long term 12. Implementation Risk: Difficult to bridge Kuali Student components to Founders existing SIS systems. Kuali Student will essentially be a very flexible package solution. Package solution not accepted by user communities within an institution who are used to purely custom development. Resistance to implement the software within the founding institutions Kuali Student Program Charter June 18, 2007 Page 75 of 76

76 Program Charter Appendix A Delivering the Functional Vision Appendix B Detailed Functional Scope Appendix C Technical Architecture Considerations Appendix D Educational Community License Appendix E Technical Architecture Deliverables & Approach Appendix F Application Development Deliverables & Approach Appendix G Founders Profile Matrix Appendix H Detailed Cost Estimates Appendix I Communications Strategy Appendix J Program Risk Assessment Kuali Student Program Charter June 18, 2007 Page 76 of 76

77 Project Program Charter: Appendix A Functional Vision Appendix A: Delivering the Functional Vision 1.1 The need for new administrative systems Today s students have grown up using personal computers, the Internet and the Web. They expect to have personalized, frictionless, online, always on interactions with the institutions they deal with, including universities and colleges. Students start building relationships with institutions when they are in secondary school, and continue these relationships, in various forms, throughout the rest of their lives. Many students take courses from more than one institution, and do some of their learning online. All students need and deserve a high level of support and guidance, to ensure they can take advantage of the full range of resources available to them. Universities and colleges are becoming larger and more diverse, offering more interdisciplinary programs, programs on multiple campuses, and joint programs with other institutions. Academic regulations and requirements are becoming more varied and complex, and programs are increasingly being tailored to the needs of individual students. External regulatory environments, governing areas such as privacy rights and the provision of aid to needy students, are also becoming more varied and complex. The admission and assessment of students is becoming more multi-dimensional, requiring the assessment and exchange of growing amounts of information. Colleges and universities need cost effective student systems that will allow them to manage this increasingly challenging learning environment, while at the same time reducing the administrative burden on faculty and staff, and providing high levels of support to students and other users. 1.2 Current student systems The first student record systems were focused on records management. They provided online versions of paper based record systems, using flat files, and could be used to print various reports, including student transcripts. There was limited support for a few key business processes, such as registration. Student information systems added support for more business processes, such as course scheduling, student admissions, financial aid, registration, degree audit, and graduation. In most cases these processes were similar to the paper based processes that preceded them. Online access made it easier for students and others to complete some tasks, but in general, these systems did not help users outside core departments complete tasks and processes. With some systems, users have reported that their work became more difficult, and took longer, after the system was implemented or upgraded. 1.3 The Kuali Student opportunity The last 40 years have seen exponential growth in the processing power of computers, the bandwidth of networks, and the capacity and cost effectiveness of information storage. The last 15 years have seen the development of the Web, and the emergence of web technologies that make a service oriented architecture practical for administrative information systems. These technological developments have made it possible to design and build a new generation of administrative systems that support the growing complexity and diversity of colleges and universities, and meet the expectations of today s students, faculty and staff. These systems Appendix A Functional Vision June 18, 2007 Page A - 1

78 Project Program Charter: Appendix A Functional Vision can anticipate the needs of users, help them make choices, and increase the likelihood that they will achieve their goals. Kuali Student will be a student-centric system, using a service oriented architecture to provide scalable support for students and other users that reflects their individual challenges and goals, identifies opportunities, and simplifies or eliminates administrative tasks. Kuali Student will improve support for learning activities and programs, and make it easier to innovate and change activities, programs and processes. Kuali Student s modular, open source, standards based design will support the use of existing commercial and open source applications, and encourage the development of new applications that extends its functionality. 1.4 The key challenges There will be both technical and functional challenges in building and implementing Kuali Student. The key technical challenges include evaluating, selecting and implementing technologies that will result in a powerful, flexible, and cost effective system. The key functional challenges will be to commit to a compelling functional vision, to deliver this functionality in Kuali Student, and to take full advantage of this functionality in each institution. 1.5 Goals of the Kuali Student functional vision A broad and compelling vision is necessary to ensure that Kuali Student delivers all the potential benefits of a next generation system. The vision, which is stated in section 2.1 of the Project Charter, sets out to achieve the following goals: To support students and other users by anticipating their needs; help them to make choices, set goals and track their progress; and reduce the time it takes them to complete administrative tasks. To support a wide range of learners and learning activities, in a wide range of institutions, and make it as simple as possible to provide support for new types of learner, activities and programs. To support a wide range of academic and related business processes, including those that cross departments and systems, in ways that work best for each institution, and make it easier, faster and less expensive to change existing processes and introduce new ones. To provide highly scalable support for users and the execution of processes, so that high levels of service can be provided, with very low incremental increases in cost, to an increasing number of users, each of whom has access to a growing range of choices and services. To build a system that complements human interactions, releasing staff from repetitive clerical and administrative tasks, and allows them to provide higher value support and services to students, faculty, and other people who need it. 1.6 Design elements of a highly effective system Seven elements are critical in the design of the system to ensure that the functionality provided in Kuali Student delivers the vision: 1. new, high level entities that make it easier to introduce new programs and approaches to learning; Appendix A Functional Vision June 18, 2007 Page A - 2

79 Project Program Charter: Appendix A Functional Vision 2. a concierge function that helps students by using information about their plans and accomplishments, available resources, and the institutions rules and opportunities; 3. the use of workflow and rules engines to implement and improve business processes, make the system highly scalable, and allow the rapid investigation and evaluation of multiple scenarios, using agreed rules and criteria; 4. the ability to configure the system, using the workflow and rules engines, to support processes developed at each institution, rather than the best practices that the system developers choose to support; 5. a modular, loosely coupled, standards based architecture, that will allow Kuali Student to work with existing and new applications; 6. appropriate access to data and information, with services to make it simple for users to find and use the information they need, when they need it, in the form that is most useful to them; and 7. a system design that supports internationalization, i.e. the use of different languages and currencies, and provision for different educational models. Each of these elements is discussed below High level entities Among the high level entities that will make it possible for Kuali Student to support a wide range of learners and learning activities in a broad range of institutions are: Person Recognizing people as unique, enduring, individuals who will have various roles, associations and group memberships over time, is critical to eliminating many of the limitations of existing systems. Earlier student systems recognized individuals only in their roles of student, instructor, etc. In Kuali Student, the high level entity is the person, and each person can have one or more roles of student, instructor, etc. Time Most existing student systems use rigid, pre-defined blocks of time such as semesters, terms, and classes, etc., each having fixed start and end dates and/or times. These fit some programs and activities, but not others. They are often difficult to change, and do not easily accommodate non-conforming activities. In Kuali Student the high level entity is the time unit, which can start and end at any date and time (year, month, day, hour and minute). Each time unit has a unique identifier, usually hidden from the user, and some time units (such as classes) can be nested within other units (such as semesters). Recurring units (such as classes) can be defined, as they are now, by their start and end times. Existing standard time blocks fit into this model, and new time units are not constrained by previously defined, standard, units. Learning unit The learning unit concept is borrowed from inventory management. Any learning activity can be a learning unit, with a unique Learning Unit Number, or LUN. Management of existing learning units (programs, specializations, courses, etc.) will be facilitated by giving them LUNs, but the real power of LUNs lies in being able to assign them to learning activities existing systems are not designed to handle. This will allow Kuali Student to be used for functions such as managing all credit and non-credit activities; defining a group of courses Appendix A Functional Vision June 18, 2007 Page A - 3

80 Project Program Charter: Appendix A Functional Vision as a unique program; or tracking individual contributions by students in particular courses; all things that are difficult or impossible with existing student systems. The way in which learning units can be combined will continue to be defined by program requirements and other applicable rules. Learning result The learning result entity will allow any information about a student s learning accomplishments to be stored as information in Kuali Student. In addition to the standard learning results, such as grades, learning results can include such things as self declared grades (e.g. student entered high school grades), assessments of meta-skill development, and qualitative evaluations submitted by instructors. Some learning results (e.g. language proficiency assessments) will not be associated with a learning unit, but where applicable, course and program rules will define how lower level learning results are evaluated to derive higher level learning results. For example, scores for essays and assignments can be evaluated to determine course grades, and course grades can be evaluated to determine program or degree completion. Learning plan A learning plan is the current collection of information about a student s learning accomplishments, activities and intentions. A student s learning plan will include information about the student s past and current courses and activities, which could be at the high school, college or university level, as well as their intentions, which could be represented by interest expressed in a degree program or major, or registration in a particular program. A student s learning plan will play an important role in Kuali Student s ability to deliver truly student-centric support. Learning resources A learning resource is any resource that is required to make learning units available to students. Learning resources include instructors, classrooms, learning delivery systems, and teaching equipment. In many cases, information about these resources will be stored in other systems (GIS, HR, etc.) The learning resource entity will provide a way to link information about these resources to information about learning units stored in Kuali Student The concierge The concierge function will be the key to making Kuali Student student-centric. The concierge supports students and other users by: anticipating their needs alerting them to necessary tasks presenting information about available choices and courses of action helping them make choices, set goals and track their progress reducing the time it takes to complete necessary tasks It uses: information about students and their accomplishments, plans and goals knowledge of institutional rules, regulations, and learning opportunities information about the experiences of other learners in similar or related situations to: identify required or recommended actions present relevant alternatives sorted according to users criteria Appendix A Functional Vision June 18, 2007 Page A - 4

81 Project Program Charter: Appendix A Functional Vision present information about the probability of success, based on the experience of others with similar achievements and goals Work flow, rules engines, and artificial intelligence techniques (such as expert systems) will be used to analyze possible courses of action and sort the results based on the user s profile and the probability that a particular course of action will meet the user s needs and help them achieve their goals. The concierge will be helpful not only to students, but also to faculty and staff. In addition, the self-service concierge functionality can be easily adapted to guide staff through the provision of in-person service to their customers Work flow and rules engines The use of work flow and rules engine technologies is central to delivering the Kuali Functional vision. Scalability, or the ability to support additional users and processes at low incremental cost, requires that processes are automated, and rules are applied with minimum human intervention. Work flow and rules engines will ensure that Kuali Student is highly scalable, and can be configured for use in a wide range of institutions. It will also ensure that process change, made possible by technological advances, can be implemented more quickly and at lower cost than with current generation systems Support for locally developed processes A student system supports core business and academic processes, many of which have evolved in each institution to reflect the role of the institution, its learners and programs, and its academic mission. Existing student systems have usually implemented processes in ways that reflect best practices agreed to by the institutions involved in the initial development. Differences between institutions mean that processes often have to be customized before a system meets institutional needs. This is usually expensive, and leads to increased maintenance and support costs. Work flow and rules engines will be used to ensure that Kuali Student can be configured to implement processes in ways that work best at each institution. Work will be required to configure Kuali Student at each institution, but the result will be a close match between what institutions do and what Kuali Student supports Modular design The standards based, loosely coupled, modular design of Kuali Student will deliver the core functionality required in a student system, and will make it possible to use other applications that either enhance included functionality, or add functionality that is not included. One example is the use of a portal application to provide the Kuali Student user interface, which will allow the interface to be configured to suit a wide variety of users, and to present information from other systems. Service oriented analysis will identify the core functionality on which higher level processes depend, and a service oriented architecture will make this functionality available to multiple applications, and to other systems. This will ensure that business and academic processes that cross traditional departments (and systems) can be supported. Appendix A Functional Vision June 18, 2007 Page A - 5

82 Project Program Charter: Appendix A Functional Vision The modular design, together with the open source licensing model, will allow both open source and commercial modules to be used in conjunction with Kuali Student. It will also allow Kuali Student modules to be used to enhance existing student systems. The use of standards wherever possible, and the publication of Kuali Student interface definitions, is essential to the formation of a community of developers and vendors who develop applications that work with Kuali Student Appropriate access to information Appropriate access to information in Kuali Student is critical to all users. Students should be able to explore possible options, and make informed decisions, based on information about rules, regulations, and the experience of other students in similar situations. Faculty and staff need easy extract capabilities and real-time access to a wide range of information to help them manage and plan activities and programs. Many existing systems make it difficult, and in some cases impossible, for all users to have timely access the information they need, in a form that is useful to them. The modular, service oriented design of Kuali Student, together with the delegation of authority to manage users and their roles, memberships, and privileges, will make it possible to give all users appropriate, timely access to information in a form that meets their needs Internationalization The Kuali student architecture will allow it to be adapted for use outside the United States and Canada, in countries that speak other languages, use other currencies, and have very different educational systems. The modular, service oriented design, with the use of work flow and rules engines, will help to make this possible. In addition, the system must provide functionality that makes it as easy as possible to change the language in which information is presented, together with the other changes required for use in different countries. 1.7 Implementation Considerations There are two key implementation considerations for institutions that implement Kuali Student: 1. The institution must have pre-requisite infrastructure in place to support the system. This infrastructure includes components such as an identity management system that allows users to maintain a single identity, regardless of their roles, memberships, and privileges, a rules engine, a portal and an enterprise service bus. 2. The implementation of Kuali Student provides an opportunity to move staff from repetitive administrative tasks to higher value, more user focused activities. If the institution has a willingness and ability to change business processes to take advantage of Kuali Student s capability, it will derive greater value from its implementation. Each of these is discussed below Key Infrastructure Components Identity Management Kuali Student requires a single Person database, which stores basic identity information for all individuals with a relationship to the institution. This will enable students, faculty, staff and other users to play their appropriate roles in the activities and transactions that Kuali Student supports. Because prospective students, parents, counselors and others often play important roles in these interactions, it must be possible for these users to easily create and use identities in the Person database. This in turn implies that some personal information in the database will Appendix A Functional Vision June 18, 2007 Page A - 6

83 Project Program Charter: Appendix A Functional Vision not be fully authenticated, and systems and applications must be able to authorize and control access in a way that reflects this. To get the maximum benefit from the use of work flow and rules engines, allow them to be used for local solutions where appropriate, and ensure that their use does not create unnecessary work for staff, and it must be clear who has the authority to define, change and approve the processes and rules that are represented. Delegation of authority, which includes the assignment of roles and group memberships, must be decentralized and easy to manage, and must reflect the organizational structures and hierarchies of each institution. The required functionality should be provided by an identity management system, which will not be delivered as a Kuali Student application. Each institution should implement a system that meets the basic requirements for the creation of identities and the delegation of authority Change management The technology and functionality in Kuali Student will allow the services provided to students, and the processes that support these services, to be very efficient and highly scalable. Many processes can be executed in real time, with no need for human intervention or review. To take full advantage of this capability, it may be desirable to change some processes within the institution. Experience has shown that there can be strong resistance to adopting new ways of executing processes and supporting users, particularly if these new approaches eliminate current paper forms and records, or replace human review with the automated application of rules. If an institution wishes to derive the full value from Kuali Student, an effective change management strategy will be required to ensure staff support change, understand why their roles are changing, and receive any retraining or upgrading required to allow them to carry out new tasks. The full benefits of Kuali Student will only be realized if the leadership in an institution is committed to supporting process innovation, and the institution has an effective change management program. 1.8 Conclusion Kuali Student will be a cost effective, modular system, capable of managing the information and supporting the processes associated student administration in the Founder institutions, online, in real time. It will be flexible and adaptable, easy to manage, and will make it easier to support new programs and improved business processes. Most importantly, it will be a truly studentcentric system, providing high quality, scalable, real-time support for students and other users, that helps them identify goals and achieve them. Appendix A Functional Vision June 18, 2007 Page A - 7

84 Kuali Student Services System Program Charter: Appendix B Functional Scope Appendix B: Detailed Functional Scope The scope of the software to be developed by the Kuali Student Program includes the core or high-priority modules that the founding institutions have determined to be part of a fully functioning Student Service System. This functionality has been grouped into 3 tiers of functionality according to the development priority. Tier 1 functionality includes the Core modules that are critical and fundamental components of a student system. Tier 2 functionality includes modules that are important for a fully functioning student system, but they have a lower priority for development or they may have large components that can be satisfied by an existing best-of-breed software product. Tier 3 functionality includes modules that the founding institutions have determined to be out of scope for this program. Partner institutions or commercial vendors are encouraged to define projects to develop software modules that fall within Tier 3 - outside the scope of this program, but complementary to the core system. This appendix provides details regarding the functional scope or business requirements that are included in Tier 1, Tier 2 and Tier 3. The functionality has been grouped into Applications that execute Business Processes that reside in traditional departmental domains. This grouping will allow the product development team to phase product releases according to development priorities. This appendix also provides a list of Applications that are considered to be outside the scope of a Student Service System. 1.0 Tier 1 Functionality The following applications have been defined as part of the Tier 1 functionality. 1.1 Curriculum Development Application Curricula are made up of learning units. A learning unit is any learning-related activity that needs to be tracked by the institution or the learner. Learning units range from very general (a degree program) to very specific (a class assignment). All credit and non-credit learning activities, whether traditional or non-traditional, are learning units. The curriculum development application consists of the 5 Business Processes outlined below and is integrated with the Learning Management Systems (LMS) Develop or modify a learning unit This is the process of proposing or modifying a learning unit at some level in a curriculum. The workflow for this process varies greatly depending on the learning unit being developed, so the process is highly configurable. For a new learning unit, a person or group chooses a learning unit template, which was previously defined in the learning unit template configuration process and stored in a repository. The template selection defines the type of learning unit that will be created. Appendix B Detailed Functional Scope June 18, 2007 Page B - 1

85 Kuali Student Services System Program Charter: Appendix B Functional Scope The following functionality is included in the Learning Unit Development module: Select a learning unit template or existing learning unit from a repository Provide initial information for a new learning unit, or modify the information associated with an existing learning unit Link to the Learning Management or other systems in which the details of the learning unit are developed and stored If the learning unit is a program, use the Degree Audit application to store and review the proposed requirements and rules for the program Submit the learning unit to the Learning Unit Approval module, according to unit or institutional rules and procedures If approved, offer the learning unit (i.e. provide the required resources, and make the learning unit available to students), using the next module If not approved, restart the Learning Unit Development module The following functionality is NOT within scope of the Learning Unit Development Module Managing the resources required to offer the learning unit (see section 1.8) Communicating information about the learning unit to prospective learners (see section 1.3.4) Review and approve a learning unit This module facilitates the review of new or previously offered learning units. The following functionality is included in the Learning Unit Approval module: Maintain the rules for approving the learning units, as adopted by the institution, consortium or other group as appropriate, in on-line rule sets Select the learning unit or units to be reviewed, or requiring approval, either manually or according to agreed rules and procedures Notify the individuals or groups who will review the learning unit(s), using unit or institutional rules and procedures Provide tracking information to the owners of the learning unit Support the review process with reports, on-line meeting services, etc. Facilitate any required consultation processes Forward any assessment or consultation results to the review team(s) Provide access to tools for modeling the effect of changes in Learning Unit rules and requirements (these may be provided by the Degree Audit application) Record approvals, including any conditions, time limits, etc., and update the information in the program requirements database in the Degree Audit application Report the results of the review to interested individuals and groups The following functionality is NOT within the scope of the Learning Unit Approval process: Develop or modify learning units that are not approved (delivered as part of another business process) Make a learning unit available to learners This module makes approved learning units available to the registration or other delivery system. The following functionality is included in the Learning Unit Availability process: Ensure the required resources are available Appendix B Detailed Functional Scope June 18, 2007 Page B - 2

86 Kuali Student Services System Program Charter: Appendix B Functional Scope Use a service to schedule the learning unit, if required Make the learning unit available to learners, using the registration or other delivery service (e.g. Course Catalogue, Schedule of Classes, Calendar, etc.) The following functionality is NOT within scope of the Learning Unit Availability process Managing the resources required to offer the learning unit (delivered as part of another business process) Assess a learning unit This module collects and consolidates feedback on the learning unit from a variety of sources. The feedback can be used in the further refinement and development of the curriculum. The following functionality is included in the Learning Unit Assessment process: Select the learning unit or units to be assessed, either manually or according to agreed rules and procedures Notify the individuals or groups who will assess the learning unit(s), using unit or institutional rules and procedures Give the individuals or groups appropriate instruments for recording their assessment Record, consolidate and summarize the assessments Distribute and/or store the results of the assessment according to unit or institutional rules and procedures The following functionality is NOT within the scope of the Learning Unit Assessment process: Implement decisions based on the results of the assessment Reports The institution s curriculum can be published directly from the curriculum application (note: this usually means published to the web). The following are published: An inventory of courses An inventory of programs (majors, minors, etc) An inventory of credentials (degrees, diplomas, etc) An inventory of requirements (degree rules, program requirements, pre-requisites and co-requisites) 1.2 Customer Contact Application The Customer Contact Application maintains the information about persons, groups and organizations that is used throughout Kuali Student Maintain Person Information Kuali Student supports the use of a single Person database, maintained by an external identity management or authentication service, to record basic identity information for every person who has a relationship with the institution. Basic identity information for a person includes a single unique identity key, together with one or more login names and passwords. The identity key is normally hidden from the user. Some contact and other demographic information may also be stored by an identity management service, together with information about the person s roles, group memberships, etc. The use of a single, institutional, Person database will allow users to access different applications and systems, regardless of their role or status within the institution. Appendix B Detailed Functional Scope June 18, 2007 Page B - 3

87 Kuali Student Services System Program Charter: Appendix B Functional Scope Kuali student will be the primary repository for Person information for users such as Prospects, Applicants, Students, Instructors, High School Counselors, Donors, etc, that is not stored by an external identity management service, including contact, demographic, role, and other information. Service interfaces will allow the Customer Contact application to access and update information in the Person database, and other applications and systems to access and update information stored in the Customer Contact application. Information is added to a person s demographic profile on an as needed basis. If there is no need for a name or an address (as might be in the case of people signing up for a campus tour) then only a person identity key is provided by the authentication service, and stored by Kuali Student as a placeholder. If the user has an ongoing relationship with the institution, additional personal information will be provided, either by the user or by applications the user interacts with. There may be more than one record per person in Kuali Student, in which case each record will be linked to the single record in the Person database by the unique identity key for the user. The following functionality is supported for Person records in Kuali Student: Name (multiple formats supported) Contact information (address, , etc). Address history can be maintained as well as multiple concurrent addresses (depending on individual institutional requirements). If there are multiple concurrent addresses then the purpose of the address is stored (e.g. send tax receipts to this address). Biographical information Additional demographic attributes. These can be configured as per Federal, State/Provincial and institutional requirements (religious affiliations, ethnicity, disabilities, etc.) Citizenship Languages As noted above, some of this information may be stored externally by an identity management service Maintain Information about groups and organizations Organizational Units can be internal (e.g. Senate Admissions Committee, Department, Faculty) or external to the Institution (e.g. government, other institutions, commercial companies). Basic information (e.g. name, relationship to other organizations) about internal organizational units should be available from an identity management service. In many cases, Kuali Student is interested in the appropriate contact people within the organizational unit. These individuals are assigned roles (e.g. high school counselor) within the organizational unit. Each individual should have a record in the Person database. The following is maintained: Name of the organization Organization type Contact information (address, , etc). Address history can be maintained as well as multiple concurrent addresses (depending on individual institutional requirements) Create and manage relationships The following functionality is included: Delegate authority for managing groups and the relationships between groups Appendix B Detailed Functional Scope June 18, 2007 Page B - 4

88 Kuali Student Services System Program Charter: Appendix B Functional Scope Allow users to manage relationships where appropriate (e.g. students can grant permission to parents to access specified information in their record) Create relationships between people (e.g. emergency contact, parent) Create a relationship between a person and a group (e.g. member of a committee, head of a department, member of a class) Create relationships between groups. This is how organizational reporting relationships are established (e.g. departments, schools, faculties) Communicate with people and groups The application supports a variety of methods of communicating with individuals and groups. Communications can be stored (creating a communications history). A mail-merge facility allows for individualized automated communications. The following are supported: Letters Bulletin boards Telephone Text messaging PDAs Portal Chatrooms The application logs all contacts, and provides a user interface for logging in-person contacts. 1.3 Enrollment Application The Enrollment Application enables learners to create learning plans, record (or declare) their learning intentions, and register in learning activities such as programs, joint programs, specializations and courses. It supports program and course selection, registration, class lists and grades. It supports the management of wait lists or other means of measuring demand for learning units and allocating places when demand exceeds supply Plan Program The Enrollment Application supports on-line declaration to a learning unit such as a program or specialization (e.g. Major in Biology). The following functionality is included: Allow learner to create and modify a learning plan (e.g. begin with a career goal, explore available learning units, record progress, and interact with advisors or third party applications to help make the right choice) Allow learners to run what-if scenarios against the degree audit tool (e.g. what if I wanted to declare a Major in Chemistry, how much of my educational history would be applicable?) Capture learner s intentions (i.e. intended learning unit) Maintain program selection rules (e.g. BSc students must declare a program in Year 2 or greater. BSc Year 1 students are in a first year unspecified/general program) Apply program selection rules against learner s educational history to verify learner s program eligibility (e.g. Major in Biology is only available for declaration to BSc students in year 2 or greater who have completed the following courses: BIOL112 and CHEM112) Access course evaluations Appendix B Detailed Functional Scope June 18, 2007 Page B - 5

89 Kuali Student Services System Program Charter: Appendix B Functional Scope Payment of an application fee (Some programs have restricted availability and an application process is required.) Accommodate special needs or services required by disabled students Check degree requirement is covered in the degree audit section Plan Course The Enrollment Application supports the maintenance of rules that determine whether or not the student is eligible to register for the selected course. This module compares information from the learner s educational history and the course parameters and enables the learner to create a timetable. The following functionality is included: Apply evaluation rules against the learner s educational history and course parameters (e.g. prerequisite checks, repeated courses). These rules may include: a. Promotional rules (defined at the program level) b. Pre-requisites (defined at the course level) c. Co-requisites (defined at the course level) d. Course restrictions e. Maximum/minimum credit loads (defined at the student level) f. Advising requirements (defined at the student level) Apply evaluation rules against the course availability a. Seat availability b. Program offerings Apply evaluation rules against the learner and course schedule (ie. Is there a conflict in the learner s schedule? Does the course schedule show a combination of courses that may create an excessively heavy workload?) Maintain rules for registration control (e.g. min/max number of courses per term, registration open dates, etc.) Allow learners to plan a timetable of courses Add/ Drop The Enrollment Application supports the on-line registration (add/drop) of courses or groups of courses (ie. standard timetable). The following functionality is included: Allows learners to register for learning units immediately following the application and evaluation processes where appropriate (e.g. when a learner is registering for a continuing education activity with minimal prerequisites) Allows learners to add or drop a course or group of courses during a specified time period Supports mechanisms for trading and switching courses, subject to applicable rules Supports creation and management of waitlists for all learning units, to enable demandside planning and the application of rules for allocating scarce places Learning group and cohort enrollment, and sequential enrollment (mass enrollment) Provides verified records of enrollment as required Interface with Financial Aid application to alert learner to implications for financial aid when adding or dropping courses Appendix B Detailed Functional Scope June 18, 2007 Page B - 6

90 Kuali Student Services System Program Charter: Appendix B Functional Scope Publish official academic record The Enrollment Application supports the publication of the official academic record. It includes course grades and standings, awards and co-curricular activities. It can be published in three different ways: A hard-copy official transcript An EDI transcript (T130 format or PESC/AACRAO XML) An unofficial transcript on the student portal Class list The Enrollment Application enables instructors and administrators to access enrollment lists (class lists) through the instructor portal. Provide specific data elements (student number, name, photo) Support recording attendance (e.g. instructor takes attendance; students login to on-line course using LMS) Provide information to support accounting and allocation of funds to reflect enrollment, attendance, resources required and other relevant information Grades Entry The Enrollment Application allows instructors to upload their final grade books directly into the system. The system also allows capturing interim grades and component grades (e.g. lab assignments). Both class lists and grade books can be integrated with a CMS such as Sakai (thus eliminating duplicate grade entry for instructors). Apply grading rules that reflect the course parameters (P/F course vs. percentage course) Calculate statistics on the class (e.g. class average, number of missing grades, etc.) Allow entry of general comments, indicators for participation or performance in a practicum Allow grade changes Reports The Enrollment Application is delivered with a set of standard reports: Student success reports (failure rates for different programs, average time to completion) Total enrollment statistics (by program, demographic profile) Verification of enrollment Non-academic record The Enrollment Application supports the entry and recording of non-academic learning results, such as participation in leadership activities, selection for athletic teams, membership of student clubs, etc. Selected information can be reported on co-curricular transcripts, or made available by the learner in other ways. 1.4 Degree Audit and Academic Evaluation Application The Degree Audit Application includes a database of requirements for all programs offered by the institution, including prior versions of these programs. It provides various on line reports on academic progress. Appendix B Detailed Functional Scope June 18, 2007 Page B - 7

91 Kuali Student Services System Program Charter: Appendix B Functional Scope Academic progress includes: Progress towards the completion of some kind of program: Degree program (BA, BSC) Degree with a major/minor (BA majoring in history) Certificate Progress in the sense of meeting academic expectations. Students who are not meeting expectations may be considered at risk Passing courses Handling credit loads Maintaining a specific grade average Monitoring of non academic progress is also supported e.g. Leadership training, internships, etc Audit Degree The Degree Audit and Academic Evaluation Application supports on line report generation of the learner s progress. The degree audit module is primarily concerned with the rules that are developed and approved using the Curriculum Development Application, and which define the requirements for a program. The following functionality is included: Apply program requirement rules (the development and maintenance of the rules is covered in the curriculum development application) Allow learners to run what-if scenarios against any set of program requirements rules Generate report indicating how far along the learner is in completing the program requirements Allow administrator to alter program requirement rules on an individual basis Allow transfer audit; assessing readiness to transfer Provide functionality for advising, from the advisor s perspective (e.g. academic advising and rules of conduct) Evaluate Academic Progression The Degree Audit and Academic Evaluation Application support the maintenance of promotional rules that determine whether the student is eligible to be promoted to the next year stage. This module can be used by schools that have promotional requirements. For example, in order to progress to third year Science, you need to have completed 30 credits of lower level Science course, not failed more than two courses, etc. The following functionality is included: Apply promotional rules against the learner s educational history Apply evaluation rules to determine academic standing Record results of promotional evaluation (new year level, new eligibility) Not in scope Course scheduling module (delivered as part of another business process) Determine Academic Risk This module is designed to identify students who are having academic difficulties so that some kind of remedial action can be taken. It uses exactly the same underlying services as the other modules in this application. The following functionality is included: Appendix B Detailed Functional Scope June 18, 2007 Page B - 8

92 Kuali Student Services System Program Charter: Appendix B Functional Scope Apply evaluation rules to determine academic standing Graduation Preparation This module is designed to identify students who are eligible to graduate and assist with the preparation for graduation ceremonies. Determine graduation candidates Support applications for graduation Prepare ceremony information Graduation and Diploma ordering 1.5 Student Financials Application The Student Financials application supports the pricing, sale and purchase of both internal and external products (e.g. courses and programs) and services (e.g. athletics and library fees). It also provides access to financial planning tools for learners Assess fees Using a rules engine, the assessment module assesses tuition fees and related charges (e.g. student society fees). The module has access to a pricing database and customer profile information. The following functionality is included: Maintain a catalogue of products and services with associated prices (credits, courses, lab fees) Maintain assessment rules Run Assessments Provide access to financial planning tools The application provides either financial planning tools, or interfaces to third party tools, that allow the learner to include fee and other financial information (including information from the Financial Aid application) while running what-if scenarios, and projecting overall costs for achieving learning objectives with various plans and assumptions. Financial planning will be enabled by the concierge application and the incorporation of concierge principles, and will include interaction with other applications and systems that generate costs for the user (enrollment, housing, dining, etc.) Invoice customer The application supports a number of invoicing options (e.g. beginning of a cycle, bi-monthly, monthly, late purchases, etc.) and a number of notification options. The following functionality is included: Allow customers to create their own payment plans Notify (Invoice) customers ( , bulletin board) Handle multiple currencies for both billing and payment Settle bill This module supports payments, refunds and the transfer of overpayments to other outstanding items on the bill. Customers can settle a bill in a variety of ways: Credit card echecks EFT Appendix B Detailed Functional Scope June 18, 2007 Page B - 9

93 Kuali Student Services System Program Charter: Appendix B Functional Scope Payroll deduction Third party payments Awards Fee waivers, exemptions, remission and prepayments Refunds can be applied as appropriate (see below) Maintain customer account All charges and payments are recorded in a customer account. The following functionality is included: Create customer account Record charges Record payments Process Refunds This module supports ability to process refunds to the student, government or other third party awarding agency, based on the rules for the item and the transaction generating the refund. Refunds generated automatically when appropriate (e.g. dropping courses within approved time limits) Request refunds on-line On-line refunds directly to bank accounts Reports The financial transactions represented by fee payments need to be reported in a number of different ways. The following functionality is included: Tax receipts for the student (T2202A in Canada, TRA97 in the US) Feeds to the institution s general ledger (FMIS) Reconciliation reports (with banks, FMIS and intermediary processing companies, e.g. Beanstream, Moneris) General financial reports 1.6 Concierge Application Kuali Student goes beyond enabling the execution of business processes at the request of various users. As a third generation information system, Kuali Student helps users identify, evaluate, select and achieve appropriate learning goals. The concierge application helps all users achieve their desired results more quickly and efficiently without them having to know the rules. The concierge concept is implemented in three ways as described below. The first two Concierge Design Principles and Service Operating Modes are included in Tier 1 scope. The third Concierge Functionality is included in Tier 2 scope Concierge Design Principles The Concierge includes a set of guiding principles for how we design all of the applications within Kuali Student. For example, one guiding principle is to ensure that all query results are filtered to display only information that we know is relevant to the user Service Operating Modes The Concierge is also implemented through functionality or logic we incorporate into every service. For example, all services will be developed to run in what-if mode if desired. Appendix B Detailed Functional Scope June 18, 2007 Page B - 10

94 Kuali Student Services System Program Charter: Appendix B Functional Scope Concierge Functionality The Concierge Application uses: information about learners and their accomplishments, plans and goals knowledge of institutional rules, regulations, and learning opportunities knowledge of how a human advisor would guide a user through the process, using the available information information about the experiences of other learners in similar or related situations to identify required actions present relevant alternatives sorted according to: o users criteria o the probability of success, based on the experience of others with similar achievements and goals The Concierge Application is implemented as a service that is available to other applications. It uses rule sets and workflow maintained in those applications and in applications in other systems, as required. The Concierge application can access information from various data stores and use it to estimate the probability of success when users consider a course of action. 1.7 Configure System Rules A number of the core domain objects in Kuali Student are defined at a very abstract level. For example, Kuali Student has defined Leaning Units and Learning Results rather than Courses and Grades. This abstract data model is essential to achieving a flexible system that will meet the needs of diverse institutions. Another aspect of Kuali Student that is required to achieve a flexible system is the use of rules engines and workflow technology to define the business rules and the process flow. However, this means that the Kuali Student System needs to be configured to work for the specific business requirements that each institution faces. Abstract data concepts such as Learning Units must be defined to the system, with all attributes defined. Business logic must be captured within the rules engines, and business process flows must be defined to the workflow engines. A Configure System Rules application is needed that will provide a user interface to enter and define the configuration details. At system implementation time, the business analysts will work with the user community to define the business logic and rules and then enter them into the system through this specialized application. It is intended that these configuration rules (or templates) can be shared across institutions within the community. Kuali Student System adopters may publish or share a repository of configuration rules to facilitate implementation by other institutions. There are 4 major functions within this application: Configure Data Abstractions This is the process of defining, reviewing, approving, configuring, and reporting the data abstractions and their attributes. For example, configure a learning unit template, which defines the attributes of a learning unit and any component learning units. The template specifies the attributes the person or group creating a learning unit may/must provide, what component learning units may be created within the learning unit, and what their attributes are. Appendix B Detailed Functional Scope June 18, 2007 Page B - 11

95 1.7.2 Configure Business Rules Kuali Student Services System Program Charter: Appendix B Functional Scope This is the process of defining, reviewing, approving, and configuring the business logic to a rules engine. This function must also provide display or reporting access to the business rules. Having a common understanding of the business rules in a single repository is often one of the most challenging aspects of business processing. For example, the degree audit module is primarily concerned with a set of rules that define the requirements for a program Configure Business Workflow This is the process of defining, reviewing, approving and configuring the institutional business process workflow. Business processing requirements will vary greatly across institutions and this function will allow end-to-end business processes to be configured or orchestrated in a custom manner. These rules will be defined to either a workflow engine or a BEPL engine Configure Tables & Codes This a simple table maintenance function that will allow each institution to create and maintain the values of codes and code descriptions that are used throughout the entire Kuali Student system. 1.8 Application Connectors Kuali Student is delivered with standard connectors to other enterprise applications. All these connectors are delivered as web services Financial Management Information System (FMIS) connector A number of transactions in Kuali Student need to be recorded in the institution s general ledger. Reference implementations could include a Kuali Financials connector and a Peoplesoft FMIS connector. For example, the following financial transactions would be included: Any application fees Tuition fees and student society fees Awards Tuition waivers (to HR system) Learning Management System (LMS) connector Kuali Student needs to be seamlessly integrated with the learning management system. Reference implementations could include a Sakai connector and a WebCT connector. For example, the following functions would be included: Class enrollment Grades Facilities Management connector To integrate with a facilities management system for controlling heat, light, opening and closing hours, janitorial services, etc Generic connectors A set of generic connectors supply basic contact information (name, address, ) and enrollment information (current enrollment and grades). This allows easy integration with other applications that are not part of the Kuali Student core: Appendix B Detailed Functional Scope June 18, 2007 Page B - 12

96 Kuali Student Services System Program Charter: Appendix B Functional Scope Recruitment Event Management Housing Athletics Alumni Library Elections Parking Student Life 1.9 Data marts and institutional reports Individual applications, such as Admissions, are delivered with a standard set of operational reports. Beyond this there will be a need for institutional reports both for internal consumption and for external agencies (Federal, State and Provincial). Although it is not part of the core project to create a complete data warehouse, Kuali Student addresses this issue by providing: Data marts (which could be implemented as views or extracts that hide the complexities of the operational database) Some sample reports Tier 1 scope includes the development of data marts for Tier 1 applications only. 2.0 Tier 2 Functionality The following applications have been defined as part of the Tier 2 functionality. 2.1 Admissions Application The Admissions Application matches prospective learners (called prospects or applicants) with learning activities (such as programs or courses) that an institution offers. The various processes (apply, acknowledge, evaluate and select) can be connected with workflow Apply for Admission Kuali Student supports on-line application for admission to a learning unit (such as a program) offered during a specified time period (e.g. a diploma program in a specified semester). The following functionality is included: Capture demographic information (if none already exists) Capture educational history (if needed) Capture applicant s intentions (i.e. intended learning unit) Payment of an application fee (if required) Automatically generate enrollment records where there is no admission evaluation (as is the case for many continuing education courses and community college programs) Handle decentralized admissions such as Graduate Studies Handle bulk feeds from recruitment systems or centralized application environments like UCAS in the United Kingdom. Allow applicant to move directly to Evaluate Applicant when self evaluation is available for intended learning unit Acknowledge Application Kuali Student supports the maintenance of rules on what information is required to make an admission decision based on the type of student (e.g. domestic or international; credit or non- Appendix B Detailed Functional Scope June 18, 2007 Page B - 13

97 Kuali Student Services System Program Charter: Appendix B Functional Scope credit) and the intended area of study. The Acknowledgment module compares received information against rules and informs the applicant of missing information. The process is run iteratively as the applicant submits additional information. The following functionality is included: Maintenance of applicant academic and non-academic history Maintenance of application completeness rules Comparing rules against what has been received by the Academic History module and the Non-Academic History module (see below) Automated notification of the applicant (via , letter or other means) Maintain Academic History Kuali Student records previous academic accomplishments. Some information may be transferred from other applications (e.g. recruitment) and some may be entered by the prospect or applicant. This module also supports the receipt of transcripts and test scores electronically either via EDI (transaction sets T130 and T138) or using the PESC XML. Multiple formats will be supported (e.g. document imaging). Academic history includes: Trans-national credentials. For example: o International Baccalaureate o British styled GCE (United Kingdom, Singapore, etc) o Advanced Placement National high school matriculation exams. For example: o French Baccalaureate o German Abitur Provincial or State curricula. For example: o Canadian provincial o Australian state US high school transcripts Post-secondary transcripts (based on the T130 EDI spec or the PESC Post-secondary transcript) Test scores (SAT, LSAT, TOEFL, GRE, etc) Maintain Non-Academic History Kuali Student records extra-curricular activities that are needed to evaluate an applicant or are needed by other areas (e.g. Alumni Affairs). Multiple formats will be supported (e.g. document imaging). Some information may be transferred from other applications (e.g. recruitment) and some may be entered by the prospect or applicant. Letters of reference Publications Art portfolios Essays Audio recordings Work experience Electronic portfolios Interview process Appendix B Detailed Functional Scope June 18, 2007 Page B - 14

98 Kuali Student Services System Program Charter: Appendix B Functional Scope Evaluate applicant Kuali Student supports the maintenance of rules which determine admissibility into a program (e.g. a SAT Math score of 500 and English score of 600). These rules reference applicant information, academic history and other criteria. The evaluation module applies the admissibility rules to individual applicants. Maintain evaluation rules Apply evaluation rules to machine readable data (transcripts, test scores) Apply evaluation rules to elements in the non-academic history that have been scored or ranked by readers (e.g. broader-based admission criteria) Allow applicants to track the progress of the evaluation on-line Allow prospects to run what-if scenarios Allow applicants to self-admit (if there is no subsequent selection process or if the rules of the program do not require an evaluation (e.g. Continuing Education) (see below) Allow the applicant to move directly to the Enrollment Application when immediate registration in a learning unit is available Provide feedback and advice to applicants, and match them to available programs Match applicants to options at other campuses or institutions when appropriate Articulate transfer credit Kuali Student supports the maintenance of rules on what courses (from other institutions) are recognized for credit. The Transfer Credit Articulation module assigns specific or general (i.e. partial) credit based on courses completed at one or more institution. The module also supports the entry of Exemptions and Waivers. Maintain transfer credit rules Articulate transfer credit Allow prospects to run what-if scenarios Select successful candidates The Evaluation module determines the admissibility of individual applicants. The selection module allows administrators to apply institutional criteria to the pool of admissible applicants. In this way an entrance class is composed. For continuing education learning units, the criteria could be as simple as payment of a fee, or being present at a prescribed time and place. For academic learning units, the criteria could be as simple as ranking applicants by GPA and as complex as ranking various broad-based admission criteria (e.g. essays, interviews, extracurricular participation and volunteer work) or meeting targets by ethnicity, nationality and any other criteria that may be relevant. Maintain selection rules Apply selection rules Reports The Admissions Application is delivered with some standard reports to help administrators further optimize the match between applicants and the institution. Summary totals for the various applicant pools Yield ratios between applicant pools and students (i.e. how many applicants were successful) Appendix B Detailed Functional Scope June 18, 2007 Page B - 15

99 Kuali Student Services System Program Charter: Appendix B Functional Scope Student success reports. These reports look for correlations between applicant profiles and success at the institution 2.2 Scheduling Application The Scheduling Application schedules the various resources required to deliver the curriculum. This includes courses, exams and distance education courses Maintain inventory of resources Scheduling is about optimizing the use of resources. The scheduling engine needs a complete inventory of resources and their characteristics: Rooms: Lecture halls, recitation rooms, Labs Equipment: Smart boards, A/V equipment Instructors Event scheduling/ad hoc bookings Maintain criteria and constraints There are various criteria and constraints (rules) that need to be applied when resources are scheduled. The criteria and constraints include: Criteria for the resolution of space and time conflicts (resources cannot be in different places at the same time) Allocation of available and required facilities and equipment Maximum room size Maximum instructor hours Preferred instructor hours Distance between buildings, etc. Room configurations Energy management (HVAC) Create schedules The heart of the scheduling application is an engine to generate schedules using the resources and constraints as inputs. The following functionality is included: Demand-based scheduling based on pre registration Optimize schedule Roll schedule Adjust schedule Publish schedule 2.3 Awards and Financial Aid Application The Awards application includes all the processes to manage internal awards, bursaries/financial aid and loans. It can support all applicable legislative and government requirements and regulations (this application will initially be configured to support federal and other regulations for Canada and the United States). It also tracks external loans on behalf of other awarding agencies. Financial planning is supported in the Student Financials application. Appendix B Detailed Functional Scope June 18, 2007 Page B - 16

100 Kuali Student Services System Program Charter: Appendix B Functional Scope Maintain awards catalogue The awards catalogue tracks every award, the conditions (or criteria) associated with the award and donor information. Offerings for specific academic cycles are also tracked. The following functionality is included: Create, modify and delete award Maintain rules for candidacy Report award statistics Apply for award Kuali Student supports an on-line application process for specific awards and bursaries. The following functionality is included: Create and modify application Submit application View application status Needs Analysis Collect financial status information Calculate financial need based on government or institutional rules Process loans This process covers loans made by the institution (as opposed to an external agency such as government) to the student. The following functionality is included: Evaluate request Track loans Calculate interest Track repayment Nominate award candidates For some awards the initial candidate pool is created through a nomination process (as opposed to application). The following functionality is included: Select students eligible for the nomination Submit nomination View status of nomination Evaluate award candidates Evaluation means applying a set of rules to build a pool of eligible applicants. The process may be entirely automated (as in the case of entrance scholarships and continuing scholarships that are based exclusively on grades). The following functionality is included: View candidates Modify rules to allow more candidates or less candidates Select and adjudicate Once an applicant pool has been built it is reviewed to build a list of successful candidates. The following functionality is included: Select successful candidates Assign award amount Appendix B Detailed Functional Scope June 18, 2007 Page B - 17

101 Renewal of awards for multi-year awards Kuali Student Services System Program Charter: Appendix B Functional Scope Offer award Successful candidates are offered an award. In some cases the offer requires confirmation. The following functionality is included: Notify winner of offer If necessary, notify donor Capture winner s choice (accept, decline, defer) Capture agreement of legal terms Capture in financial aid history Monitor successful candidate s eligibility Successful candidates must continue to meet the terms of the Award. Failure to do so may result in award being withdrawn. Detect ineligibilities Notify external agencies of ineligibility Withdraw award; refund award to university if student withdraws Interface to Enrollment Application, to allow real time application of financial aid rules when students are adding or dropping courses Disburse award Award money can be disbursed in a variety of ways. For every disbursement method there is a process to reverse the transaction (as the conditions under which the award was made may no longer apply). The following functionality is included: Apply award directly against fees Disburse via direct deposit Produce cheques Reference back to government agency or university Report financial transactions The financial transactions represented by the disbursement of awards need to be reported in a number of different ways. The following functionality is included: Tax receipts for the recipient of the award (T4A in Canada) Manage awards budgets Feeds to the institution s general ledger (FMIS) Reports to the Development Office and donor Track the funds available for each award Administer government loan processes Government agencies may require institutions to report on a student s academic status. An institution may base eligibility of their own awards on government loan assessments Report academic status Receive government loan data Support interest-free status for government loans Appendix B Detailed Functional Scope June 18, 2007 Page B - 18

102 Kuali Student Services System Program Charter: Appendix B Functional Scope 2.4 Concierge Application Kuali Student goes beyond enabling the execution of business processes at the request of various users. As a third generation information system, Kuali Student helps users identify, evaluate, select and achieve appropriate learning goals. The concierge application helps all users achieve their desired results more quickly and efficiently without them having to know the rules. The concierge concept is implemented in 3 ways. The first two Concierge Design Principles and Service Operating Modes are included in Tier 1 scope. The third Concierge Functionality is included in Tier 2 scope Concierge Functionality The Concierge Application uses: information about learners and their accomplishments, plans and goals knowledge of institutional rules, regulations and learning opportunities knowledge of how a human advisor would guide a user through the process, using the available information information about the experiences of other learners in similar or related situations to identify required actions present relevant alternatives sorted according to o users criteria o the probability of success, based on the experience of others with similar achievements and goals The Concierge Application is implemented as a service that is available to other applications. It uses rule sets and workflow maintained in those applications and in applications in other systems, as required. The Concierge application can access information from various data stores and use it to estimate the probability of success when users consider a course of action. 2.5 Data marts and institutional reports Individual applications, such as Admissions, are delivered with a standard set of operational reports. Beyond this there will be a need for institutional reports both for internal consumption and for external agencies (Federal, State and Provincial). Although it is not part of the core project to create a complete data warehouse, Kuali Student addresses this issue by providing: Data marts (which could be implemented as views or extracts that hide the complexities of the operational database) Some sample reports Tier 2 scope includes the development of data marts for Tier 2 applications. 3.0 Tier 3 Functionality - Out of Program Scope Applications This section provides a description of the business functions that are not part of the scope of the Core Program. This does not mean that these business functions are not considered to be part of the Kuali Student Service System, but rather that they will not be delivered as part of the 5 year program being sponsored by the founding institutions. These functions could possibly be implemented by Partner institutions. Appendix B Detailed Functional Scope June 18, 2007 Page B - 19

103 Kuali Student Services System Program Charter: Appendix B Functional Scope 3.1 Recruitment Application The Recruitment Application contains the functions to run recruitment campaigns. These include educational fairs, school visits etc. It needs to be integrated with the Admissions Application as prospects may become students. While developing the Recruitment application is out of scope, development of interfaces from the core of Kuali Student would be considered to be in scope. 3.2 Event Management The Event Management functionality overlaps with scheduling functionality and provides staff time-savings. 3.3 Housing Application The Housing Application looks after applications for residence, provisioning residences with services, rents and conference facilities. While developing the Housing application is out of scope, development of interfaces from the core of Kuali Student would be considered to be in scope. 3.4 Athletics Application The Athletics Application schedules teams and games. It integrates with the student system as players are students. While developing the Athletics application is out of scope, development of interfaces from the core of Kuali Student would be considered to be in scope. 3.5 Alumni Application The Alumni Application maintains an Alumni Portal. It provides an on-going community for students who have graduated. While developing the Alumni application is out of scope, development of interfaces from the core of Kuali Student would be considered to be in scope. 3.6 Family Financial Planning Tools to assist students in budget planning are not in scope. However, there are number package software solutions do this. While developing a Family Financial Planning module is out of scope, development of interfaces to external packages would be considered to be in scope. 3.7 Elections Tools to support the Student Elections process are not in scope. This application is out of scope however integration to the student system may be within the scope through generic connectors. 3.8 Student Life This application provides tools to support all aspects of student life on campus. This application is out of scope however integration to the student system may be within the scope through generic connectors. 4.0 Functionality Out of Scope for a Student Service System This section provides a description of the business functions that are considered to be out of scope of a Student Services System. These are major systems requirements that institutions are expected to satisfy via another product or solution. However, application connectors to these systems may be in scope for Kuali Student. Appendix B Detailed Functional Scope June 18, 2007 Page B - 20

104 Kuali Student Services System Program Charter: Appendix B Functional Scope 4.1 Campus Calendar This application is used to manage other events around campus. 4.2 Student Portfolio This application is out of scope, however integration is within scope. A Portfolio application may satisfy some of the requirements of the non-academic record. 4.3 Learning Management System The Learning Management System provides tools to create course content, facilitate student participation, communication and collaboration, and assess and evaluate student performance. This application is out of scope however integration to the student system is within the scope. 4.4 Financial Management Information System (FMIS) The Financial Management Information System manages the institution s general ledger and accounting requirements. This application is out of scope however integration to the student system is within the scope. 4.5 Facilities Management System The facilities management system monitors and controls campus facilities. It is used to control building and room availability and maintenance for heat, light, opening and closing hours, janitorial services, etc. It may also contain campus maps, locations, pictures, facilities available. This module is tied closely into the Maintain Inventory of Resources and the Scheduling (room assignments) process. 4.6 Library System The Library system provides support for accessing, integrating, and personalizing the information available in a Library. This application is out of scope however integration to the student system is within the scope. 4.7 Parking System The parking management system provides support for the administration and service provision for a parking utility. This application is out of scope however integration to the student system may be within the scope through generic connectors. Appendix B Detailed Functional Scope June 18, 2007 Page B - 21

105 Project Program Charter: Appendix C Technical Architecture Considerations Appendix C: Technical Architecture Considerations 1.1 Technical Architecture Overview The architecture of Kuali Student is designed to meet the high degree of flexibility and configurability proposed in the functional design. The first characteristic of Kuali Student is that it is an SOA (Service Oriented Architecture) built on web service technology and written in java. Although many Java Enterprise applications are service based in a conceptual sense (all objects are accessed via service interfaces) the SOA web service approach is different in several respects: The design places great emphasis on entity modeling and service modeling The artifacts of the design phase are XML schemas and service definitions Services should be designed so they can be deployed remotely. Web services is the preferred platform for remote deployment (and the core technologies here are SOAP, WSDL and UDDI) In short, XML is the platform. Business processes can easily be implemented by orchestrating a set of underlying services. Automated tools such as BPEL (Business Process Execution Language) engines facilitate this. The second distinguishing characteristic of Kuali Student architecture is the greatly expanded role of business intelligence. This is implemented through the following technologies: Rules engines Workflow engines The use of rules engines takes the traditional separation of business logic and presentation in an n-tier architecture one step further by completely externalizing business logic. Changes to business logic can be defined to the system without any programming changes. This also introduces the possibility of artificial intelligence in the system as one of the outputs of a rules engine can be a new set of optimized rules. It is not within the scope of Kuali Student to build infrastructure components, although we may need to develop web service wrappers for existing products. We will use existing open source products for BPEL engines, an Enterprise Service Bus, Workflow and Rules Engine Technology and UI frameworks. By using a formal open source software assessment methodology, such as OpenBRR, OSSM, or QSOS, we will evaluate and select software from well-established opensource organizations, including: Apache Foundation Eclipse Foundation JBoss Sun Kuali Student will seek a best-of-breed solution rather than an integrated technology stack from one particular provider (such as Sun or JBoss). This is to prevent the equivalent of vendor lock-in in the open source domain. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 1

106 Project Program Charter: Appendix C Technical Architecture Considerations Because of the large scope and complex requirements of Kuali Student, and the varying stages of maturity of the various open source solutions, it may be necessary for our project to become involved with the development of some of the necessary open source components. Our involvement with other projects will need to be evaluated on a case by case basis, and only done when necessary for the overall success of the project. 1.2 Service and Schema Definitions The flexibility and configurability of Kuali Student will depend, in part, on the stability of the service contracts which are expressed in Web Service Definition Language (WSDL). The preferred style of web service definition for an SOA implementation is the Document-literal (doc/lit) as opposed to Remote Procedure Calls (RPC). The reason for this is that doc/lit hides the implementation details of a service more effectively. Consequently, the schemas that express the entity model of Kuali Student must also be carefully managed as they are a core component of the service contracts. The infrastructure must cover: A versioning strategy for schemas and services Repositories for service definitions and schemas that contain meta-data such as ID, version number and a natural language description. Wherever possible, Kuali Student will either use or integrate industry standard schemas and service definitions. This includes: PESC (Post secondary Education Standards Council) schemas. IMS Global Part of the design phase of Kuali Student will include alignment with these standards. There may also be an alignment with OKI OSIDS (Open Knowledge Initiative Open Service Interface Definitions) as they cover some of the same business domain (albeit with a different technology). 1.3 Service Registries Run time versions of Kuali Student will require service registries that allow consumers of services to find, bind, and execute services. Each service has a unique address. There will also be different addresses for different versions of a service. While Kuali Student may not need the full capabilities of Universal Description, Discovery and Integration (UDDI), it cannot rely on location information being hard-coded in configuration files. Kuali Student will need some intermediate solution that allows: Service locations to be defined and changed dynamically References to the service definition repository (see above) Different locations for different versions of a service Kuali Student may also need registries of service consumers. Knowing who is consuming a particular service will help: Implement security Implement changes to service definitions (so consumers can be changed or notified) Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 2

107 Project Program Charter: Appendix C Technical Architecture Considerations The service registry problem must be solved in such a way that a developer can work on a single service and create a sandbox of services that is isolated from all other environments. 1.4 Web Service Framework One of the main attractions of SOA built on web services is that it is platform independent. In theory it should not matter whether services are developed in.net or Java. In practice there are enormous efficiencies of scale in adopting a single technology stack. It is also very important that the web service technology stack is standards compliant. In this context the Web Service Basic Profile can be used as a guide in tool selection Requirements The web service framework covers the standards and tools that will be used to implement web services. To some extent the standards will be dictated by the toolsets that are used. For example, Axis 2.0 implements a particular version of SOAP and WSDL. The toolsets include both the runtime implementations and the tools required to create WSDLs. The web service technologies that are needed for the project include: A runtime SOAP engine An XML-Java binding framework Tools for developing WSDLs Tools for developing schemas Solution Approach In the open source space the main contenders for a complete web service stack are: Sun JAX-WS 2.0 Apache Axis 2.0 JBossWS As the flexibility and performance of the XML-Java binding framework is a critical component of the stack, it may be necessary to choose yet another product for this. JiBX often gets the highest ratings for this. 1.5 Service Container Framework All Kuali Student services need to be built according to the same design principles. Simple examples or templates will be developed, along with associated documentation, and will be used to illustrate basic design stereotypes. The use of such templates will mean that design problems will only have to be solved once for the entire project. Implementations and support of existing service should also be made easier by the use of standard templates Requirements Each service can run as an autonomous application. Services have their own internal architecture. There may be several different service stereotypes that call for slightly different architectures: So-called headless services that have no user interface component: Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 3

108 Project Program Charter: Appendix C Technical Architecture Considerations o Entity related services (whose primary function is maintaining part of the entity model) o Task oriented services Orchestration services that may or may not have a user interface component The functions that are covered by templates include: Lifecycle management (start, stop, cycle) Binding to a data source Binding to a user interface layer Caching (where there are special performance requirements) Logging (note: logging may be more than a purely technical requirement if the Concierge application needs access to a very detailed database of customer interactions) Solution Approach As the primary data source for Kuali Student will be a relational database, individual services could use Object Relational Mapping (ORM) technology. Possible solutions include: ObJectrelationalBridge (OJB), an Apache product that integrates with the Spring framework. Hibernate The details of logging and caching can be entirely removed from Java code by using aspect oriented programming techniques. This is supported by the Spring AOP (Aspect Oriented Programming) framework. For services that include a user interface layer, the project could consider Struts or Spring MVC (Model View Controller). One key decision that needs to be made is whether the standard service template should include Enterprise Java Bean (EJB) technology. 1.6 Enterprise Service Bus Although Kuali Student will eventually have to integrate with other enterprise systems, the main focus of the ESB is to enable consistent communication between Kuali Student web services Requirements A discovery mechanism (find and bind) Support for asynchronous and synchronous messaging Support for multiple message patterns: o Fire and forget o Request-response o Publish-subscribe The endpoints are web services Optional: a web service management console Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 4

109 1.6.2 Solution Approach The main contenders in the open source space are: Kuali Rice - ESB Apache: Service mix Sun: Open ESB JBoss ESB Kuali Student Service System Project Program Charter: Appendix C Technical Architecture Considerations 1.7 Information Privacy and Security Protection of personal privacy is of paramount importance for Kuali Student, and security is an up-front design requirement, rather than an afterthought. While more of the functional privacy and security considerations are outlined in the functional architecture section, a fundamental privacy consideration of the system is that minimal personal information is collected wherever possible- information is only requested when required to complete a business transaction. This requires that as a person moves through their lifecycle with their institution, they will gradually build up a personal profile depending on their interactions with the institution, rather than necessarily being required to divulge a large amount of personal information up front. Individuals should also retain control over their personal information wherever possible, and should be able to control the release of that information. As the Concierge layer will depend on personal information in order to provide a richer set of options for people interacting with Kuali Student, there will be a tension between internal privacy and the ability to provide personalized services. Traditional software development security challenges are even more complicated within a Service Oriented Architecture. By including strong security involvement in the architecture and design phases, conducting frequent, thorough code reviews, following security best practices such as OWASP, and adhering to a formal development methodology, these security risks can be mitigated. Among the challenges to be addressed are the following: Firewall limitations: Since services operate on the standard http and https ports 80 and 443, traditional port based firewalls will need to be supplemented by application layer XML-aware firewalls Immature standards: While there is an emerging body of standards within the SOA and Web Services spheres, these standards are neither complete, well tested, nor widely implemented Performance challenges: Due to the loosely coupled nature of SOA based web services, latency is a serious concern for enterprise environments. Digitally signed and encrypted messages add an additional performance penalty there is usually a direct inverse relationship between performance and security. Trust issues: Traditional security policies, procedures, and data classification levels exist within a single system boundary, while SOA based web services expose data beyond those boundaries While the various services contained within Kuali Student will need to comply with the various WS-Security standards, where practical, security functionality should also be available as Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 5

110 Project Program Charter: Appendix C Technical Architecture Considerations discrete services, such as authentication, authorization, encryption and auditing, composable as part of an orchestration to fulfill a particular business process Requirements The services must address the following security needs: Authentication Authorization Confidentiality Data Integrity Non-repudiation Manageability Accountability Interoperability Policy Enforcement The W3C Web Services Architecture document ( outlines a number of additional security requirements and other considerations. Most of these are addressed by the Oasis WS-Security standards, namely: WS-SecureConversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy The WS-Security protocol incorporates security features in the header of a SOAP message and thus works at the application layer, ensuring end-to-end security. The protocol includes details on the use of SAML and Kerberos, and certificate formats such as X.509. Certain transactions may only require point-to-point security, and security can be enforced via traditional SSL/TLS over https. Note: Kuali Student will not be building the infrastructure that implements these standards. Ut it will be selecting products (from Apache, JBoss or Sun) that implement WS security standards. Kuali Student must also comply with applicable Local, State, Provincial, and Federal privacy and security legislation, such as FERPA and PIPED Solution Approach The Web Service Framework and Enterprise Service Bus that we select must implement the WS-I Basic Security Profile ( This profile outlines a set of non-proprietary Web services security specifications, along with clarifications to those specifications which promote interoperability. One possibility would be to use the WWS4J WS-Security handler for Axis. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 6

111 Project Program Charter: Appendix C Technical Architecture Considerations 1.8 Identity A rich set of identity services, including strong group and permission management, are necessary underpinnings of our person-centric system. Identity based security controls allow flexible access to resources, and by exposing identity as a service, individual applications need not duplicate authentication and authorization functions. There must also be a clear separation between authentication and authorization within the identity services. Recognizing that many of our institutions are complex, decentralized organizations, our identity services must be able to address these challenges without requiring a single, centralized, metadirectory. Most institutions are likely to have an existing identity framework that Kuali Student will need to interoperate with. Identity must be cleanly and clearly separated from other services, in order to simplify connecting Kuali Student to existing institutional infrastructure. In addition to managing identity information within the boundaries of a single institution, modern identity systems must be built from the ground up to incorporate identity data from external sources. The principles of User-Centered Identity Management (often known as Identity 2.0) are rapidly gaining currency, and will be expected features of any modern system in the coming years. Moving beyond simple federation, user-centered identity protocols will allow people to move rich identity data between disparate identity systems. Students arriving at our institutions in the future will likely wish to migrate identity data from high-school, college, and other systems, and may even expect to re-use an existing identifier and authenticator from these systems Requirements The Kuali Student identity services must support the Security Assertion Markup Language. SAML is the foundational XML standard for exchanging authentication and authorization data between an identity provider and a service provider. The latest version, SAML 2.0, has been translated into a set of SOA based web service specifications by the Liberty Alliance, and released as ID-WSF 2.0. The identity services must also support XACML, the extensible Access Control Markup Language. XACML is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies. In addition, the services should support the concept of virtual organizations, as well as distributed and delegated role management Solution Approach Where possible, Kuali Student should develop a services wrapper on top of existing identity solutions. A back-end LDAP database is likely necessary, with OpenLDAP being the likely candidate software, although ApacheDS is worth examining. In terms of supporting SAML and Federation, while the current version of Shibboleth only supports SAML 1.1, it is currently the most adopted federation technology within higher-ed. Shibboleth has committed to supporting SAML 2.0 by adopting the OpenSAML 2.0 libraries as part of the next major Shibboleth release, 2.0. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 7

112 Project Program Charter: Appendix C Technical Architecture Considerations It is also worth investigating Grouper and Signet, the other Internet2 identity middleware projects, for inclusion in our reference distribution. Grouper is a collaborative group management tool, while Signet is a distributed privileges management tool. 1.9 Portal The Kuali Student project will develop a user interface rich in capability for presenting information across a spectrum of interaction modes, from expert focused to passive summary. An illustration of expert focused mode is an insurance adjuster reviewing and making judgments on claims. The whole display is used to present a complex and comprehensive array of information, useful to a trained expert who has detailed knowledge of both process and data semantics. A use case of passive summary mode is a student noticing that a requested library book is now available through a small cameo window in the corner of her display. In the middle of the spectrum are the actions of the user who notices a message has arrived (passive summary), and then takes action to view what messages are available; eventually drilling down into the mail service to read messages, file messages, respond to messages, or label messages with tags; gradually transitioning to expert focused mode for a short period, and then moving on to other areas, such as reviewing her student loan status. The user interface must be consistent in its conventions for display, input, and navigation. There must be no training required, only the assumption of generic understanding of how the interface works through self-revealing selection and navigation options. The facility must be rich in capabilities for personalization and assistance, not to instruct the user in the workings of the interface, but for achieving success in interactions with business processes. Requirements for functional richness and conformity across all application areas argue for the type of user interface provided by a high-function portal. Furthermore, it is clear that from the user s point of view, application boundaries will be indistinct, if they exist at all. Composed application services will also be free to range their interactions across all parts of the spectrum. If we don t start with a portal framework, we will end up building one. The portal must allow for what we may call intelligent personalization a mechanism for interpreting everything about the user known to the identity management service, as well as their previous interactions, and then guiding them through appropriate business processes to achieve their objectives. This means enabling what has been called the concierge layer. The portal is not expected to implement the concierge, but must supply services to it Requirements Our requirement is for a high-function portal of proven enterprise quality which can provide standards based (e.g. WSRP, JSR-168, and JSR-286) service interfaces, and can evolve to support the needs of a concierge. Dynamic keyboard/screen/pointing-device interactions must Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 8

113 Project Program Charter: Appendix C Technical Architecture Considerations be well provided for. The objective is to provide for rich user interactions with low latency 1. At this time, the requirement is best expressed technically as a need to support AJAX 2, but a more abstract expression of this sort of capability needs to be formulated. The chosen portal must demonstrate an intention to evolve with both the listed standards and the user interface requirements listed below. Once a user is engaged in expert focused mode, a portal provides little added value to the interaction. We do not expect this to be the dominant mode for student interactions with Kuali Student Solution Approach We will select an open source product which is available for future development to the higher education community. Our choice is uportal from the JA-SIG. Key points in its favour include: JSR-168 compliance WSRP demonstrated Available for co-development, and influenced evolution Designed-in device independence Layered rendering model Built-in skin support Proven enterprise operational quality Ongoing development Credible roadmap Wide acceptance We intend to work with the JA-SIG developers on the directions and evolution of the uportal product to ensure that Kuali Student needs for personalization, user interface richness, and accessibility will be met. One issue that needs to be addressed is the problem of employing JavaScript in aggregating frameworks such as portals. Another issue still needing clarification is the connection between the SOA-compliant application service set, and the presentation services of the portal. The question arises: Can more than one portal implementation meet our requirements? We must consider that future Kuali Student adopters are likely to have already chosen an enterprise portal for their institutions. Can we allow for a range of standards-based choices, as we intend with database solutions? 1 There is ongoing discussion about whether server side solutions introduce more or less latency through page refreshes when compared to the overhead of downloading masses of JavaScript over slow links such as dialup connections. This concern has been raised by representatives of the Open University. 2 See also the dōjō JavaScript toolkit. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 9

114 Project Program Charter: Appendix C Technical Architecture Considerations 1.10 User Interface The understanding of user experience and mechanisms for enriching user interactions will evolve over the next few years; there will be advances and changes during the Kuali Student project. The standard repertoire of well-understood actions will expand, as will users expectations for personalized options, meta-information, and general richness of the interfaces they engage. It is our intention that the user interface of Kuali Student will stay current with these developments Requirements We require compliance with (a yet to be determined level of) accessibility standards catalogued by the W3C WAI. See WAI Home and WAI International Policies. Legislation relevant to these standards includes: US 1998: Rehabilitation Act Amendments (Section 508) US 1990 Americans with Disabilities Act (ADA) CA 1977 Canadian Human Rights Act Users of the services must be assumed to have no training in either the use of the interface or the business processes underlying the applications presented. The interface must reveal both the available functionality and the information semantics. Users may be assumed to have a generic knowledge of basic navigation and selection options that a browser (or other information-access appliance) presents. There is a strong requirement for site-level customization to enable institutional branding. This may be best achieved through user-selectable skins, with institutional defaults Solution Approach The overall approach to user-interface and user-experience issues will be based on an established standard user-centered design process, incorporating user research, user profiling, user scenarios, proven design concepts, and user testing. Consistency across all applications will be achieved through use of uniform portal facilities and common design styles, subject only to user customization and personalization. Adopting an evolving portal framework (uportal) will ensure that the Kuali Student user interface stays current with end-user expectations for interactive richness. Rules of style will be codified and adhered to by core developers. Style guides will be published to enable partners to follow the same rules and ensure consistency of style in their user-interface contributions. All user interactions will assume a standard set of presentation and navigation conventions. The Adaptive Technology Resource Centre at the University of Toronto is in the process of founding what is now called the Flexible UI Project. It is their intention to develop a user interface transformation engine which will mediate between a user and a user-facing service to Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 10

115 Project Program Charter: Appendix C Technical Architecture Considerations address accessibility needs. uportal is one of the target services of this initiative 3. By adopting uportal as its display management framework, Kuali Student will inherit the accessibility levels supported through Flexible UI Browser Support The Kuali Student user interface is delivered through standard browsers. All user interface components will have to be tested on the browsers Kuali Student supports. This will include: Internet Explorer Firefox Safari Note: We talk of browsers here, but we should remember the possible future need of addressing other information appliances. Theoretically, application developers should be insulated from such concerns, but they should be careful to avoid any sort of browser lock-in Rules Engine The rules engine is the heart of the business intelligence of Kuali Student. Academic rules (degree requirements, criteria for merit based awards, admission requirements) form a large part of the student domain and can be defined directly to a rules engine. Although there are standards for the manner in which rules engines are invoked (JSR-94) there are no standards for expressing rules (there is not such language as a Rules ML ) Requirements A rule consists of a condition and an action. For example: If citizenship = Canadian and degree = Arts then cost per credit = 300 dollars. A ruleset is a collection of rules. In the classic n-tier design paradigm, the presentation layer was separated from the business logic layer. The use of rules engine technology takes this paradigm one step further by completely externalizing business logic so that it can be configured dynamically. There are three components to rules engine technology: A rules execution engine that can work recursively A rules repository (or database) One or more rules authoring tools The requirements for these components are: The rules execution engine should be JSR-94 compliant Rules should be stored as simple XML files. The rules authoring tools should support 3 simple stereotypes: Decision tables Flow charts Procedural rules 3 Note that uportal already has a built-in user interface transformation engine. The uportal theme transformation retargets structured output to different end-user devices. This is a potential anchoring site for the Flexible UI layer. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 11

116 Project Program Charter: Appendix C Technical Architecture Considerations The semantics of specific business domains can be layered on top of these stereotypes. Thus a degree audit application may require one set of interfaces, while an admissions application might require a completely different set of interfaces. If Kuali Student is going to reap the benefits of pushing rules authoring to the user community, then building these user interfaces will have to be part of the core development effort Solution Approach There are three distinct approaches (and a variety of hybrid variations): 1. Use an existing open source rules engine out of the box. There are three possibilities: a. JBoss rules b. Drools (an archived version before it became JBoss rules) c. JESS 2. Take an existing product (or part of a product, such as the expression evaluator of Drools: Janino) and extend it to meet the requirements of the project 3. Kuali Student creates its own rules engine technology (just as Kuali Foundation created a workflow engine). Regardless of which option is created, Kuali Student will probably have to create its own rules authoring interfaces Workflow Workflow is a particular case of BPEL (Business Process Execution Language). In a workflow, one or more nodes are work lists that require human mediation. Once the human mediation is complete, control can be passed to either another human process or an automated process. Ideally, a workflow service is built directly on top of a BPEL engine Requirements Architectural o Non-proprietary process language o Graphical programming tool o Nodes within a workflow can be human(s) or system(s) o Configurable persistence mechanism o Is built on top of a BPEL engine Functional o Administrative UI to manage workflows in progress o Conditional routings including loops o Change logging for objects passing through workflow o User & role definitions must interface with external security service(s) o A graphical user interface for routing o Configurable UI for human nodes o Configurable notification mechanism, e.g. , task lists Note: Workflow patterns devised by Prof van der Aalst of Eindhoven University of Technology can be used as an evaluation aid. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 12

117 Project Program Charter: Appendix C Technical Architecture Considerations Solution Approach One approach is to simply create a work list service and a notification service. Then a BPEL engine can be used to cerate workflows. If, on the other hand, Kuali Student is looking for a bundled product, some of the options include: o Kuali Rice - Enterprise Workflow o JBoss jbpm o Object Web Bonita o Enhydra Shark o Open WFE 1.14 Database Database independence is a design criterion for Kuali Student. While many of our institutions run Oracle as our enterprise database, our goal is to consciously avoid using triggers and any other proprietary features that will lock us into a single database product. This will have performance implications that need to be managed. While mandating the use of only ANSI standard SQL may meet this criterion, we may also require an object-relational mapping and persistence framework. Our assumption is that a relational database will be necessary for the system. One area that needs to be explored is where the boundary should be for accessing information from the database, and how many databases should exist. Potentially, each service could independently access an independent database. On the other extreme, no service would access a database except for a single service, called by all other services, which accesses a single database. It is important in either scenario to fulfill all reporting requirements, and consider the role of an institutional data warehouse. In addition, the question of whether all developers should connect to a single central database for all of their development and testing also needs to be resolved. One potential scenario would see a single master MySQL database at a central location, with developers running local copies of MySQL with the data synchronized via CVS/Subversion. It may also be worthwhile to have each developer in each institution connecting to their current institutional database during development (Oracle/DB2/whichever)- this would allow us to develop and test multiple databases at an early stage. Performance concerns, particularly for a large, critical application that will see peek loads of tens of thousands users, are great. These are magnified by the loosely coupled nature of a Service Oriented Architecture, where latency is already increased through the use of multiple services. Particular attention to database performance will be needed to address these issues. Since individual database products have different needs for tuning, we will likely need to develop specific database adaptors and best practices for a core of supported databases Requirements Supported databases must meet the following requirements: ANSI SQL 99 compliance ACID compliance Full Unicode support Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 13

118 Project Program Charter: Appendix C Technical Architecture Considerations Transactions Updatable views Query caching Sub Selects Multi-Slave Replication SSL Encrypted Communications Foreign Key support Referential Integrity constraints The implementation of the database must: Support multiple teams working concurrently in the same areas Real time reporting needs of the user community Solution Approach Based on the requirements, MySQL and PostgreSQL are the likely open source candidates for the development and distribution database. Of the two products, MySQL is more familiar to our development teams. In addition, by dumping the MySQL database as a plain text.sql file using mysqldump, the database can be checked into Subversion, greatly simplifying the distribution of the main test database. If we require an ORM/transactional framework, Hibernate is the likely candidate, although OJB could also be considered. Since individual database products have different needs for tuning, we will likely need to develop specific database adaptors and best practices for a core of supported databases Development Infrastructure Developers working on Kuali Student will need: 1. A toolkit 2. An organized development environment In order to develop web services in Java, the toolkit needs to include: A Java development environment Integration with the code management tool Integrated JUnit testing An XML authoring environment (for schemas and XML-java bindings) A Spring development environment (preferably with code completion) Database access tools (to create and run SQL queries) Support for build and deployment The plug-in architecture of the Eclipse platform provides an open and extensible toolkit. There are existing open-source Eclipse plug-ins for all the tools listed above. In theory each developer could create an Eclipse IDE with all the needed plug-ins. However, in practice this is time-consuming and finicky work. The project would be well served by having a central copy of Kuali Eclipse with all the plug-ins pre-configured. Developers could then download and unzip Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 14

119 Project Program Charter: Appendix C Technical Architecture Considerations this central copy (no installation would be required). The team responsible for maintaining the Kuali Eclipse toolkit would be responsible for: Keeping the plug-ins up-to-date (i.e. periodically releasing a new version of Kuali Eclipse Providing central support for developers who are having problems with the toolkit While a centrally maintained set of development tools will help ensure that our developers will work in similar pre-configured environments, we should also not rule out the potential for customization or enhancement by individual developers, as long as these do not compromise the main shared environment, or hinder the handover of code to another developer taking over a task. Beyond the developer s personal environment, everything should be shared, from the code repositories to staged versions of packages, as well as data resources. The development environment for an SOA project built on web-services will not look the same as a development environment for a traditional J2EE application. Each service will need its own autonomous build and deploy environment. The various stages of the development environment (test, integrate and production) now apply to each individual service. Although many of the lessons learned in developing traditional J2EE applications will be useful, this new environment presents a slightly different set of problems that will have to be solved during the technical architecture phase of the project. One possible approach (which would need a lot of further work and refinement) includes: A developer sandbox does not need to include the entire code base. It should only need: o The code for the service that is being worked on o Stubs for services being consumed Access to the server where the test version of that service is being deployed Other services that are being consumed need to be readily available, likely running as local instances at each institution. The database is a specific instance of a service that needs to be readily available during the development of other services. As discussed in section , at one extreme there could be one central database (although with test, integration and production instances) for the entire project. There are two problems with this model: 1. Performance 2. The database becomes a bottleneck for projects that require changes to the data model At the other extreme, each developer could have a database instance on their desktop. The problems with this model are: 1. Additional management issues for the desktop 2. Increased complexity of synchronizing changes to the data model and the software There is likely a good compromise solution along these lines: 1. One central canonical database for the entire project. 2. One copy at each partner institution 3. A synchronization policy to ensure consistency between the canonical database and the local instances, perhaps using the main code repository Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 15

120 Project Program Charter: Appendix C Technical Architecture Considerations 1.16 Configuration Management Requirements There will be a common code repository which will maintain a change history of each component so that any version can be retrieved. There will be a nightly build of each stage where changes have been promoted. Each component will bear a set of tags indicating which stage of testing it has achieved (DEVL, EVAL, VERF, PROD). Configuration goes beyond component version selection; there will also be various database versions which enable different aspects of testing Approach We will use Subversion for the code repository. Builds will be accomplished through Ant scripts, likely under the control of a build management tool such as Luntbuild. Promotion to the production stage will be under the control of the Release Manager. Defining the different stages and their uses as well as the rules for interaction by the developers, testers, and configuration managers, is a sub-project in itself. This must be an early deliverable in the overall Kuali Student project Release Management Throughout the lifecycle of Kuali Student, we will be releasing multiple versions of services we develop, and bundling them together to form an identifiable and supportable release. Substantial additional testing, including integrating current versions of supported infrastructure components such as database and workflow engines, must be conducted before finalizing a release. Release management is the responsibility and process of controlling the selection of component versions that make up a particular named/numbered release of Kuali Student. The challenge is to identify the set of deltas (changes) that distinguish one release from another. CVS and Subversion don t have mechanisms that support this very well. Release management will be an important aspect of the VERF and PROD instances. A tool that can maintain release information at the required level of detail must be identified Test Drive System In order to showcase our development efforts, and to be able to conduct end-to-end usability and functional testing, it will be necessary to create a Kuali Student Test Drive system. This Test Drive system will allow functional, technical, usability, and security experts to review the integration between all of the services that we develop, and will also allow end users to explore the complete product. As well, the Test Drive will be invaluable for conducting presentations and demonstrations for a wider audience. The scope for the Test Drive will need to be very clearly defined. Since the Test Drive will be an invaluable marketing tool, we may wish to make it available for anyone to explore, or lock it Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 16

121 Project Program Charter: Appendix C Technical Architecture Considerations down so that only Founders and Partners can use it. We may also wish to create a downloadable version of the Test Drive, perhaps as an ISO or a VMWare image, which would allow other institutions to experiment with their own copy of the Test Drive. Another scope question that needs clarifying is how many of the infrastructure components, such as the database, portal, identity infrastructure, etc, need to be included as part of the online or downloadable Test Drive. Integration with other Kuali projects, such as Kuali Finance or Kuali Research Admin, to create a complete online Kuali University is also something we may wish to explore in conjunction with the other Kuali project staff. Program Charter Appendix C - Technical Architecture Considerations June 18, 2007 Page C - 17

122 Project Program Charter: Appendix D ECL License Appendix D: Educational Community License The Kuali Student Service System Project will be licensed under the Educational Community License V2.0. Version 2.0 has recently been approved by the Open Source Initiative and text for the license will shortly be available on their web site: Following is the text of the Educational Community License ( ECL ) Version 2.0. It consists of the Apache 2.0 license, modified to change the scope of the patent grant in section 3 to be specific to the needs of the education communities using this license. The original Apache 2.0 license can be found at: TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this Appendix D - Educational Community License June 18, 2007 Page D - 1

123 Project Program Charter: Appendix D ECL License License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. Any patent license granted hereby with respect to contributions by an individual employed by an institution or organization is limited to patent claims where the individual that is the author of the Work is also the inventor of the patent claims licensed, and where the organization or institution has the right to grant such license under applicable grant and research funding agreements. No other express or implied licenses are granted. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: You must give any other recipients of the Work or Derivative Works a copy of this License; and Appendix D - Educational Community License June 18, 2007 Page D - 2

124 Project Program Charter: Appendix D ECL License You must cause any modified files to carry prominent notices stating that You changed the files; and You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. Appendix D - Educational Community License June 18, 2007 Page D - 3

125 Project Program Charter: Appendix D ECL License 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPE DIX: How to apply the Educational Community License to your work To apply the Educational Community License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[ ]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within thirdparty archives. Copyright [yyyy] [name of copyright owner] Licensed under the Educational Community License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Appendix D - Educational Community License June 18, 2007 Page D - 4

126 Program Charter: Appendix E Technical Architecture Deliverables & Approach Table of Contents 1 OVERVIEW PLANNING & PREPARATION SELECTION CRITERIA PRODUCT SPACE SECURITY GUIDELINES TRANSACTIONAL INTEGRITY GUIDELINES MODULE STEREOTYPE GUIDELINES DEPLOYMENT GUIDELINES STANDARDS DEFINE THE SCOPE AND REQUIREMENTS FOR THE CONFIGURATION APPLICATION PRESCRIBE THE CRITERIA AND APPROACH USED IN DEFINING PROOF OF CONCEPT PILOT DEVELOP DETAILED SCHEDULE OF RESOURCES AND ACTIVITIES DEVELOP COMMUNICATION AND COLLABORATION STRATEGY ARCHITECTURAL FRAMEWORK SIGNOFF DEVELOP TECHNICAL ARCHITECTURE CREATE INTEGRATED SANDBOX ENVIRONMENT TECHNOLOGY STACK SELECTION IDENTIFY AND RESOLVE DEFICIENCIES IN THE TECHNOLOGY STACK TECHNOLOGY TRAINING PLAN INTEGRATE TECHNOLOGY STACK ARCHITECTURE REVIEW AND SIGNOFF DEVELOPMENT INFRASTRUCTURE CREATE INTEGRATED DEVELOPERS WORKBENCH CREATE USER-INTERFACE COMPONENT STEREOTYPES CREATE WEB SERVICE STEREOTYPES CREATE WEB SERVICE FRAMEWORK DESIGN PRODUCT DEVELOPMENT LANDSCAPE DEPLOY DEVELOPMENT INFRASTRUCTURE CREATE SERVICE-CONTRACT MANAGEMENT FRAMEWORK ARCHITECTURE REVIEW AND SIGNOFF DEVELOP CONFIGURATION APPLICATION DESIGN THE CONFIGURATION APPLICATION DEVELOP THE CONFIGURATION APPLICATION IMPLEMENT THE PROOF OF CONCEPT PILOT UPDATE DEVELOPERS WORKBENCH UPDATE DEVELOPMENT INFRASTRUCTURE ARCHITECTURE REVIEW AND SIGNOFF...19 Appendix E - Technical Architecture Approach June 18, 2007 Page E - 1

127 Program Charter: Appendix E Technical Architecture Deliverables & Approach 1 Overview The Kuali Student program will create an Service Oriented Architecture (SOA) built entirely on an open-source technology stack. The Kuali Student program is committed to using existing infrastructure software and not investing directly in infrastructure development. This, combined with the constraint to limit the software selection process to the open-source community imposes very clear boundaries on the program. It may not be possible to build the perfect SOA. The maturity of existing open-source offerings will dictate what is possible. Conversely, the conceptual architecture will determine which products are examined and selected. So there is an iterative relationship between designing the architecture and product selection. The development of the Technical Architecture for Kuali Student is divided into 3 phases: 1. Technical Architecture selecting the technology stack and integrating it into a fully working SOA stack. 2. Development Infrastructure creating an integrated developers workbench, complete with module stereotypes, procedures for use, and installed development infrastructure. 3. Develop Configuration Application the design and development of a number of infrastructure services that will make up the Configuration Application. The diagram below illustrates these phases within the context of the full project. Kuali Student Phased Modular Approach Functional Gate Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Program Management &Communications Jul 2007 Nov 2007 Dec 2007 Apr 2008 May 2008 Sep 2008 Oct 2008 Mar 2009 Apr 2009 May 2009 Jun 2009 July 2009 (Users & IT Functional) Application Architecture - Business Requirements - Process models - ER models - High Level Service Models Service Modeling R1 (Infrastructure and Cur. Dev.) Contract Design R1 (Infrastructure & Domain 1) Service Modeling R2 (Domain 2) Contract Design R2 (Domain 2) Technical (IT Architects & Developers) Technical Architecture -Technology proofs -SOA standards Development Infrastructure - Developers workbench - Procedures - Standards Develop Configuration Application - Configuration Infrastructure -Proof of concept Pilot Software Design & Development R1 (Infrastructure and Cur. Dev.) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support Appendix E - Technical Architecture Approach June 18, 2007 Page E - 2

128 Program Charter: Appendix E Technical Architecture Deliverables & Approach The remainder of this document will outline the Kuali Student Technical Architecture Development methodology detailing the activities, deliverables and resources required to develop the system Appendix E - Technical Architecture Approach June 18, 2007 Page E - 3

129 Program Charter: Appendix E Technical Architecture Deliverables & Approach 2 Planning & Preparation The Technical Architecture Framework is a detailed architectural blueprint that expands on the Technical Guiding Principles contained in the Charter document. It will show in detail how the various components of the technology stack will interoperate to create an SOA. During the Planning & Preparation stage, the structure and outline of the Technical Architecture Framework is developed. From this, an approach and set of activities are defined that will guide the Technical team to complete the Technical Architecture Framework deliverable. 2.1 Selection criteria Define a set of criteria to be used when selecting open source products for the SOA architecture (below). The majority of these criteria can be taken directly from OSS Watch an open source software advisory service. 2.2 Product space Outline the product space for the open source product selection process. The selection process will have to be limited to a prescribed set of products because a full and comprehensive search would be too time consuming. Identify cases where there is an obvious candidate. 2.3 Security guidelines Describes how security issues will be solved in the context of our SOA built on web-services: 1. Authentication 2. Authorization 3. Transport layer security These solutions become embedded in the specifications for the module stereotypes (see section 4.3) 2.4 Transactional integrity guidelines Describe how the question of transactional consistency will be solved. These solutions become embedded in the specifications for the module stereotypes (see section 2.5). 2.5 Module stereotype guidelines This section of the Technical Architecture Framework will describe the various kinds of module stereotypes: 1. User facing module 2. Agnostic business service 3. Orchestration module Define an approach for developing each stereotype. 2.6 Deployment guidelines Develop a conceptual framework for solving the following implementation issues: 1. Performance 2. The design of logical and physical services environments for the product development and product implementation landscapes. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 4

130 Program Charter: Appendix E Technical Architecture Deliverables & Approach 2.7 Standards Enumerate standards that are relevant to the project and that will be adopted: o W3C and WS* standards o Java community standards (Eg JSR-168, JSR-94) o Domain specific standards (PESC-AACRAO, IMS, OSID) 2.8 Define the scope and requirements for the Configuration Application The Configuration Application consists of 3 core services: o A Dictionary Service o A Search Service o A Rules Definition Service At this stage in the project the general requirements for these services are sketched out. These services are used in assembling the proof of concept pilot (see below 5.1) 2.9 Prescribe the criteria and approach used in defining proof of concept pilot Scenarios will be used to test the major milestones of the Kuali Student architecture - Technology Stack Selection and Integration, Stereotypes, and the Configuration Application for Kuali Test Drive. These scenarios must be broad enough to test each component, deep enough to test all major facets, and complex enough to properly exercise each component. This section will specify the criteria and approach that provides this breadth, depth, and complexity Develop detailed schedule of resources and activities The following activities will be performed: Develop a detailed work plan and work break down structure for the Year 1 activities: Application Architecture, Service Modeling and Contract Design Identify the roles, resources and skill sets required to complete all tasks Identify the size and composition of the teams Determine how each institution will organize their work to collect their specific business requirements. Identify checkpoints where external reviews of the project plans, artifacts and deliverables should be reviewed Develop communication and collaboration strategy At each institution: Identify institutional meetings and discussions Identify institutional wikis, websites, communication plans Determine how face-to-face meetings will be conducted and how information should be brought back to the institution from the face-to-face meetings Across institutions: Develop a process for collating information from each institution into the overall Kuali wiki and documentation Develop schedules for face-to-face meetings and discussions Determine how interactions with the Technical team will be conducted Appendix E - Technical Architecture Approach June 18, 2007 Page E - 5

131 Program Charter: Appendix E Technical Architecture Deliverables & Approach 2.12 Architectural Framework Signoff An external review of the approach and the Technical Architectural Framework will be conducted by industry experts who have experience in developing SOA architectures. Examples of such experts include: Thomas Erl IBM architects SUN architects The deliverable will be a 3-4 page critical report from one or more external reviewers. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 6

132 Program Charter: Appendix E Technical Architecture Deliverables & Approach 3 Develop Technical Architecture During this phase of the Technical Architecture, the technology team will select a stack of open source web products that can be assembled to form a Service Oriented Architecture. These products will be integrated into a trivial hello world application in order to demonstrate that they can work together. 3.1 Create Integrated Sandbox Environment During this step, the architects work with the systems infrastructure team (DBAs, system administrators, security, etc.) to configure, purchase and install a sandbox development workbench that will allow team members to download and test products for the product selection phase. The minimum requirements are: o A set of servers. The physical location of these servers will initially be at one institution, but may be distributed across multiple institutions as the research work continues. o Java development IDE (Eclipse) with the following plugins: o Maven build plug-in o Subversion plug-in o Tomcat plug-in o A database access plug-in o A database server (mysql) o A Tomcat servlet engine o A Subversion repository o A uportal 3.0 instance Appendix E - Technical Architecture Approach June 18, 2007 Page E - 7

133 Program Charter: Appendix E Technical Architecture Deliverables & Approach 3.2 Technology stack selection Using the selection criteria prescribed in section 2.1 above, the technology team will select and test the products that make up the technology stack. The technology stack consists of the following components: The technology team will be sub-divided into three groups. Each group takes responsibility for a different layer of the architecture: Group 1 - The user facing layer o Portal (JSR 168 compliant) Group 2 - The orchestration layer o Rules engine (JSR 94 compliant) o Workflow engine o BPEL engine o Service bus o Service Registry Group 3 - The back-end service layer. o Authentication service o Authorization service o Web service engine (SOAP 1.2, WSDL 1.1) Individual members of each group take ownership of individual components. Products are downloaded and tested. Choices are documented. The selection process for each component Appendix E - Technical Architecture Approach June 18, 2007 Page E - 8

134 Program Charter: Appendix E Technical Architecture Deliverables & Approach is subject to peer review. The technology selection process is one of the activities through which SOA standards are expressed. It is in this phase that decisions are made about Kuali Rice. The deliverable for this step is a working set of infrastructure components which have not yet been integrated. 3.3 Identify and resolve deficiencies in the technology stack Some of the products selected in 3.2 may not have all the features required by Kuali Student. For example, the rules engine may not have an adequate user-interface, or the Portal may not integrate properly with the authorization service. During this step, the technology team will work to investigate the issues and identify solutions. There are 3 possible strategies for dealing with deficiencies: 1. A work-around is identified 2. A simple fix is identified and implemented 3. A fix is identified but the implementation is sufficiently costly that a new item needs to be added to the project plan or a new product needs to be selected The deliverable from this step is a list of deficiencies with proposed fixes and/or workarounds. 3.4 Technology training plan Once the initial technology choices have been made, product and technical training may be required before detailed testing and implementation of products can occur. For example: If the Portal product is uportal 3.0, the team would want to organize training through JA- SIG. If the web-service engine is Axis, then the team would want Axis training. The technology team will determine what training they require to complete the architecture phase. The lead architect (in consultation with the Program Director and the architecture committee) will plan and schedule the training. The deliverable from this step will be a series of hands-on training sessions. 3.5 Integrate technology stack During this step, the technology team will exercise the entire technology stack in an integrated fashion. In this proof-of-concept a user will sign onto the portal, execute a hello world servlet that uses a web-service via the web-service engine and access the database to display some value. This is a technology-stack proof of concept, not an architecture proof-of-concept. Various products may be running at different institutions, depending on the evolution of the developer s sandbox and the features that are being tested. For example: o Portal at institution A o Authentication server at institution B o Database at institution C The deliverable is a successful hello world execution of the servlet. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 9

135 Program Charter: Appendix E Technical Architecture Deliverables & Approach 3.6 Architecture Review and Signoff Before moving on to the next stage of the development of the Technical architecture, a review of the proposed technology stack will be performed by external industry experts. Two leading SOA experts will be asked to review and comment on the proposed SOA technology stack. The deliverable will be a 3-4 page critical report. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 10

136 Program Charter: Appendix E Technical Architecture Deliverables & Approach 4 Development infrastructure This part of the technical architecture project establishes the tools and procedures required for product development. It will create an integrated developer s workbench, complete with module stereotypes, procedures for use, and installed development infrastructure. 4.1 Create integrated developers workbench The next major stage in the project involves integrating a set of third party frameworks (eg Spring) and creating a set of code stereotypes that developers will be able to use throughout the project. There are 3 classes of stereotypes: o User Interface stereotypes (using various UI frameworks). See 4.2 below o Business service stereotypes (that will use core frameworks like Spring, Log4J, Acegi). See 4.3 below o Stereotypes for the persistence layer (that may use an ORM framework) However, technologists need the tools to start working in these stereotypes, so this first part of this phase involves extending our toolkit. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 11

137 Program Charter: Appendix E Technical Architecture Deliverables & Approach Specialized toolkits can be assembled for technologists working on different layers of the SOA. 1. Group 1 - workbench for developers working on user-facing components a. Portlet development tools b. AJAX framework (dojo?) c. Portal build and deploy scripts 2. Group 2 - workbench for developers working on orchestration a. BPEL plug-ins b. Workflow tools c. Rules engine d. ESB e. WS engine (eg Axis) 3. Group 3 - workbench for developers working on back-end services a. Database access tools b. ORM framework plug-ins c. WS engine (eg Axis) plug-ins Testing tools need to be available to all three groups: o Unit testing (eg JUnit) o Performance testing (eg JMeter) Tools are bundled as Eclipse distributions with all the necessary plug-ins configured. The distributions are subsequently managed by the release/deployment team. Developers should be able to download and unzip the toolset with no configuration required. A key problem that will be addressed is how a developer will work on one or more services in a sandbox when: Those services may have to access remote services (developer needs access to stubs) Those remote services may have to access the services the developer is working on Appendix E - Technical Architecture Approach June 18, 2007 Page E - 12

138 Program Charter: Appendix E Technical Architecture Deliverables & Approach The deliverable for this step is a Kuali Eclipse Programmer Workbench including: Workbench Documentation Workbench Tutorials Coding and naming standards 4.2 Create user-interface component stereotypes During this step, Group 1 developers (UI components) will develop one or more stereotypes that will be sample portlets. The first activity will be to refine the list of stereotypes that will be required by developers. The stereotypes will be delivered through the Portal and will demonstrate how user interface components interact with services. Other technical issues to be addressed include: Integration with a data dictionary (that specifies labels, drop down lists etc) Integration with the Ajax framework (see section 4.1 above) User interface standards During this step, there is a key interaction point with the Application Development team who will be defining UI Style Templates and Re-usable UI Components in conjunction with the UI Expert and the FLUID project The deliverable will be a manual for developers and one or more Hello World UI component stereotypes that can be downloaded and run. 4.3 Create web service stereotypes During this step, Group 3 developers (Backend Services) will develop one or more stereotypes for a Web Service. The first activity will be to refine the list of stereotypes that will be required by developers. The web-service stereotypes are the blueprints for business services. There may be separate stereotypes for business agnostic services and entity related-services. The functions that are covered by the module stereotypes include: Lifecycle management (start, stop, cycle) Binding to a data source Binding to a user interface layer Caching (where there are special performance requirements) Logging (note: logging may be more than a purely technical requirement if the Concierge application needs access to a very detailed database of customer interactions). Exception handling The deliverable will be a manual for developers and one or more Hello World web services stereotypes that can be downloaded and run. It will also include software design guidelines for such things as: o Concierge design principles o Concierge service operations (to be included in ALL services) o Service granularity o Maximum practical level of composition o Re-use versus modularity trade-offs Appendix E - Technical Architecture Approach June 18, 2007 Page E - 13

139 Program Charter: Appendix E Technical Architecture Deliverables & Approach 4.4 Create web service framework During this step, Group 2 developers (Orchestration) will develop one or more stereotypes for a Web Service Framework. The first activity will be to refine the list of stereotypes that will be required by developers. There are three common aspects of systems architecture that need to be solved in a unique way in the SOA-WS world: Security Transactional Integrity Orchestration Although there has to be an architecture-wide solution, the solutions includes components in the module stereotypes. It is this framework that implements the WS* standards. The deliverable for this step is a set of three trivial services that are built according to the stereotypes developed in 4.3 above. These services will be orchestrated in a way that guarantees security and transactional consistency. The deliverable includes a manual for developers. 4.5 Design product development landscape During this step, the technical architects will work with the DBAs and the systems infrastructure team to design the product development landscape. Design considerations include: o Testing strategies and procedures o Development environment requirements: DEVL (shared development), EVAL (functional integration testing), VERF (performance & operational testing), PROD (Kuali Test Drive). o Logical and physical server configuration o Logical and physical database design o Procedures for migrating developers code from one environment to another o Use of code management tools such as Subversion o Backup & Recovery procedures o Security and access requirements o Naming conventions The deliverable from this step is an infrastructure design document including operational procedures (configuration management, code management, security administration, backup/recovery, etc.). 4.6 Deploy development infrastructure During this step the technical team will work with the DBAs and the systems infrastructure grups to install and deploys the elements of the development landscape. Hardware will be purchased and installed, software products will be installed (database, portals, tomcat, etc.). Scripts will be built to manage the environment. Specific items include: o Code migration scripts o Backup/recovery scripts o Database build scripts o Ant scripts o Etc. The deliverable from this step is a fully installed and functional development landscape. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 14

140 Program Charter: Appendix E Technical Architecture Deliverables & Approach 4.7 Create service-contract management framework During this step, the technical team will design the name spaces, directory structures, and URL framework. As XML schemas and service contracts are produced, they will need to occupy intelligible namespaces. For example: or There needs to be a well documented directory structure as well as versioning rules and promotional rules. Some early prototype schemas and interfaces from the functional team can be used as test cases. The deliverables from this step are registered URLs, namespaces, directory structures, and documented migration procedures. 4.8 Architecture Review and Signoff Before moving on to the next stage of the Technical architecture Develop Configuration Application - a review of the proposed SOA architecture and Developers Workbench will be performed by external industry experts. Leading SOA experts will be asked to review and comment on the deliverables produced during this phase. The deliverable will be a 3-4 page critical report. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 15

141 Program Charter: Appendix E Technical Architecture Deliverables & Approach 5 Develop Configuration Application A key deliverable of the Technical Architecture is the creation of a Proof of Concept application. This involves creating an integrated prototype that will exercise every part of the technology stack including (but not limited to): o A working instance of the portal (with sign-on and provisioning) o Code that illustrates all the module stereotypes o An application that demonstrates the flexibility of the technology stack to be configured to meet the requirements of multiple institutions: o The data configuration functionality o The rules engine o The workflow engine (service orchestration) o The authorization service The proof of concept application will be a fragment of an application from the functional design, most likely from the Curriculum Development Application regarding Learning Units. The point is not to explore the business design but to exercise every part of the technology stack. In order to demonstrate this application fragment or proof of concept, the system Configuration Application must first be developed. The Configuration Application is itself a set of services that will be built upon the Service Oriented Architecture. This phase of the Technical Architecture will develop the Configuration Application, demonstrate the SOA architecture and prove its ability to be used as a platform to develop the Kuali Student Service System. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 16

142 Program Charter: Appendix E Technical Architecture Deliverables & Approach 5.1 Design the Configuration Application Kuali Student is highly configurable in three different respects: Core entities like the Learning Unit can be configured to represent familiar domain objects such as Degree programs and Credit Courses. Business logic is entirely externalized in a rules engine Business processes can be configured through a orchestration engine Creating the templates and configuring them for individual institutions is done through the Configuration Application. There are three parts of the Configuration Application that are not available off-the-shelf : 1. The Dictionary Service 2. The Search Service 3. The Rules Definition Service For these three components there are 2 possible strategies: 1. Evolve existing UBC SIS infrastructure components 2. Adopt (and possibly modify) Rice components Appendix E - Technical Architecture Approach June 18, 2007 Page E - 17

143 Program Charter: Appendix E Technical Architecture Deliverables & Approach Configuring Business processes will hopefully be achieved through a third party tool. The Configuration Application is designed like any other Kuali Student Application. o A set of requirements and processes are defined in conjunction with the R1 design team (they are the users in this context) o The teams conduct service modeling exercises o Service contracts are defined 5.2 Develop the Configuration Application The service contracts for the Configuration Application are implemented. User interfaces are developed as required by the design. 5.3 Implement the proof of concept pilot At this point the Technology Architecture Team has completed 3 core deliverables: o An SOA built on an open-source WS stack o A collection of module stereotypes o A Configuration Application In order to prove that the framework works, the Technology Team works with the Application Team to implement a Proof of Concept Pilot. This will be a narrow slice of the Curriculum Project (such as developing Learning Unit templates). 5.4 Update Developers Workbench Final refinements are made to the developer s toolkit(s). These are available for download from the Kuali Student website along with references to documentation. 5.5 Update Development Infrastructure All the infrastructure and policies for the development phase are finalized and documented (developer sandboxes, DEVL, EVAL, VERF, PROD) o How the developer sandbox works o How builds work o How deployments work o How the database environments work The documentation includes training manuals for new Kuali developers. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 18

144 Program Charter: Appendix E Technical Architecture Deliverables & Approach 5.6 Architecture Review and Signoff Before completing the Technical architecture phase, a review of the Configuration Application and the Proof of Concept Pilot (a thin slice of the Curriculum Development application) will be performed by external industry experts. Leading SOA experts will be asked to review and comment on the deliverables produced during this phase. The deliverable will be a 3-4 page critical report. Appendix E - Technical Architecture Approach June 18, 2007 Page E - 19

145 Appendix F - Application Development Approach Appendix F - Table of Contents 1 OVERVIEW PLANNING & PREPARATION COLLECT AND REVIEW EXISTING ARTIFACTS DEVELOP APPROACH FOR DOCUMENTING USE CASES DEVELOP APPROACH FOR CAPTURING CONCEPTUAL OBJECT MODEL DEVELOP APPROACH FOR BUSINESS PROCESS MODELING DEVELOP DETAILED APPROACH FOR SERVICE DECOMPOSITION DEVELOP DETAILED APPROACH FOR USER INTERFACE COMPONENTS DEVELOP DETAILED APPROACH FOR REFERENCE IMPLEMENTATION CONFIGURATION DEVELOP APPROACH FOR DESIGNING THE CONCIERGE DEVELOP DETAILED SCHEDULE OF RESOURCES AND ACTIVITIES DEVELOP COMMUNICATION AND COLLABORATION STRATEGY METHODOLOGY REVIEW AND SIGNOFF APPLICATION ARCHITECTURE CREATE CONCEPTUAL OBJECT MODEL CREATE BUSINESS PROCESS MODELS GATHER INSTITUTIONAL SPECIFIC REQUIREMENTS COLLECT AND DOCUMENT USE CASES IDENTIFY TEST CASES FOR REFERENCE IMPLEMENTATION MAP INSTITUTIONAL REQUIREMENTS TO KUALI FEATURES IDENTIFY SERVICE CANDIDATES PARTITION SERVICES INTO APPLICATIONS AND DOMAINS VALIDATE APPLICATION ARCHITECTURE AGAINST CONCIERGE DESIGN PRINCIPLES EXTERNAL REVIEW AND SIGNOFF SERVICE MODELING COLLECT AND EXTEND USE CASES DEVELOP AND EXTEND TEST CASES FOR REFERENCE IMPLEMENTATION DEFINE SERVICES - ITERATION VALIDATE SERVICE DEFINITIONS ITERATION DEFINE SERVICES ITERATION VALIDATE SERVICE DEFINITIONS ITERATION USER INTERFACE DESIGN SIGNOFF SERVICE CONTRACT DESIGN COLLECT AND DOCUMENT USE CASES DEVELOP AND EXTEND TEST CASES FOR REFERENCE IMPLEMENTATION SERVICE CONTRACT DESIGN ITERATION VALIDATE SERVICE CONTRACT DESIGN ITERATION SERVICE CONTRACT DESIGN ITERATION VALIDATE SERVICE CONTRACT DESIGN ITERATION Appendix F - Application Development Approach June 18, 2007 Page F- 1

146 Appendix F - Application Development Approach 5.7 DEVELOP USER INTERFACE RE-USABLE COMPONENTS SERVICE CONTRACT DESIGN SIGNOFF SOFTWARE DESIGN & DEVELOPMENT DESIGN AND DEVELOPMENT OF USER FACING (UI) COMPONENTS UI Design with Users Software Design of UI Components Software Design of Business Controller Develop Web Application Components Develop Business Controller Components DESIGN AND DEVELOPMENT OF SERVICES Software Design of Services Service Orchestration Design Code and Test Services Configure and Test Orchestrated Services PREPARE DOCUMENTATION PACKAGE PRODUCT RELEASE AND IMPLEMENTATION SUPPORT PACKAGE AND RELEASE SOFTWARE SUPPORT IMPLEMENTATION PROJECTS PRODUCTION SUPPORT AND TRANSITION TO SUPPORT ORGANIZATION SAMPLE DOCUMENTATION TEMPLATES AND FORMATS ENTITY RELATIONSHIP DIAGRAMS ENTITY DEFINITIONS BUSINESS PROCESS MODELS SWIM LANE DIAGRAM USE CASES SERVICE DESCRIPTION TEMPLATE SERVICE STACK DIAGRAM SERVICE X-REFERENCE DIAGRAM OBJECT MODEL (CLASS DIAGRAM) SERVICE INTERACTION DIAGRAM (SEQUENCE DIAGRAM) SERVICE CONTRACT SPECIFICATION SERVICE REGISTRY TEMPLATE...40 Appendix F - Application Development Approach June 18, 2007 Page F- 2

147 Appendix F - Application Development Approach 1 Overview As there is no standard, off the shelf methodology for Service Oriented Analysis and Design, the Kuali Student project will use a hybrid of the methodologies proposed by Thomas Erl 1 and a group of IBM IT architects 2. There are number of unique aspects of the Kuali Student Program that must be considered when putting together a methodology and approach: 1. Most methodologies are designed to build systems or products according to one set of business requirements. The application is customized to the specific needs of the company or institution. Kuali Student is intended to be a very flexible system that will meet the needs of any number of diverse institutions with very different business requirements. We must define an efficient method for gathering business requirements and use cases, but rather than focusing on ensuring there is a complete set of requirements, the focus is on finding a diverse set of requirements with particular interest in edge cases. 2. A number of the core domain objects in Kuali Student are defined at a very abstract level. For example, Kuali Student has defined Leaning Units and Learning Results rather than Courses and Grades. This abstract data model is essential to achieving a flexible system that will meet the needs of diverse institutions. However, this means that the methodology and approach must accommodate the design and development of these objects. The system will need to be designed to configure these abstractions to express recognizable domain objects such as courses, sections and programs. 3. Another aspect of Kuali Student that is required to achieve a flexible system is the use of rules engines and workflow technology to define the business rules and the process flow. The methodology needs to be adjusted to allow for the collection of a number of archetypal business rules as well as a number of edge case business rules. This is very different than collecting a complete, unique set of business rules that will be built directly into the application logic. The archetypal rules will become the basis for the reference implementation that will be delivered with Kuali Student software. The Application Development for Kuali Student is divided into 6 phases: 1. Planning & Preparation developing the specific methodology and work plans 2. Application Architecture - a high level Service Oriented Analysis and Design of the entire student domain 3. Service Modeling - the detailed analysis and design for each domain or release of Kuali student (the first release is currently assumed to be Curriculum Development). 4. Service Contract Design the design and specification of the Service Contracts 5. Software Design & Development the design and development of the Services and the user interfaces to present the services. 6. Product Release and Implementation Support 1 Service Oriented Architecture. Thomas Erl. Prentice Hall See Appendix F - Application Development Approach June 18, 2007 Page F- 3

148 Appendix F - Application Development Approach The diagram below illustrates these phases within the context of the full project. Kuali Student Phased Modular Approach Functional Technical Gate Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Program Management &Communications (Users & IT Functional) (IT Architects & Developers) Jul 2007 Application Architecture - Business Requirements Technical Architecture - Process models -Technology proofs - ER models -SOA standards Nov High Level Service Models Dec 2007 Development Infrastructure Service Modeling R1 - Developers workbench (Infrastructure and - Procedures Cur. Dev.) - Standards Apr 2008 May 2008 Develop Configuration Contract Design R1 Application (Infrastructure & Domain 1) - Configuration Infrastructure -Proof of concept Pilot Sep 2008 Oct 2008 Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure and Cur. Dev.) Contract Design R2 (Domain 2) Mar 2009 Apr 2009 Release 1 & Implement Test May 2009 Jun 2009 Re-plan / Re-Architect / Implement & Transition to Support July 2009 The remainder of this document will outline the Kuali Student Application Development methodology detailing the activities, deliverables and resources required to develop the system. Appendix F - Application Development Approach June 18, 2007 Page F- 4

149 Appendix F - Application Development Approach 2 Planning & Preparation During this step, a detailed application development plan and approach for is created. The detailed plan prescribes the approach that will be used in a number of core design areas and confirms the deliverables for each stage. 2.1 Collect and review existing artifacts 1. Collect all the existing artifacts from the work that was done at the Boston and Vancouver workshops (entity models, flowcharts, service candidates etc). 2. Collect any appropriate artifacts already existing at our institutions. 2.2 Develop approach for documenting Use Cases Determine the approach and format for capturing and documenting the use cases, including how the use cases are amalgamated into a single Kuali student collection as opposed to five versions, one for each institution. Section 8.5 below provides an example of the documentation format. In traditional projects, use cases capture business logic that is then encapsulated in program logic. In Kuali student business rules are expressed in rules engines and business processes are captured in BPEL and workflow. In Kuali student use cases are captured in order to: Identify outliers (if the underlying business engines can handle these extremes, then they should be able to handle anything). Identify archetypes or patterns. For example, an awards catalog and a course catalog may be examples of a more general pattern: an inventory control system. This activity should also include the development of instructions that outline the practical steps to collect use cases. What format? text, diagrams or both. What classification schemes should be used (ie how to classify uses cases for easy retrieval from the web site). Design the use case web-site. Establish a process of review and comment (internal Kuali comments and external public comments). Approach for collecting data - Prescribe how the work is done. e.g. web site, blogs, wiki s 2.3 Develop approach for capturing conceptual object model Determine the approach and artifact formats for capturing and documenting the objects at a very high level. Section 8.1 below provides an example of the documentation format. 1. The documentation techniques can include things like UML diagrams with cardinalities 2. Diagrams can be supplemented with English documents 2.4 Develop approach for business process modeling Determine the approach and artifact formats for capturing and documenting the business processes. Section 8.3 below provides an example of the documentation format. Appendix F - Application Development Approach June 18, 2007 Page F- 5

150 Appendix F - Application Development Approach 1. The documentation techniques can include things like BPM activity diagrams and sequence diagrams 2. Diagrams can be supplemented with English documents 2.5 Develop detailed approach for service decomposition The fundamental question we need to answer here is How do we define services as efficiently as possible, while not constraining our system design? Develop the detailed approach for identifying service candidates and creating service definitions. We need to agree on the variations that we will incorporate into the Thomas Erl approach to support work flow and rules engines. Section 8.6 below provides an example of the documentation format. 1. Determine tools and templates for modeling the Service Candidates 2. Determine tools and templates for documenting Service Contracts 2.6 Develop detailed approach for user interface components Develop the approach for defining and documenting the user interface design screen standards, headers, footers, help, screen labels, and screen templates for various screen types such as inquiry, update, table display, user security, etc. Other questions to be answered include: Determine how we will interact with other products and projects such as FLUID, Sitemesh, MyFaces, Exadel, etc. How will we use any of these product outputs 2.7 Develop detailed approach for reference implementation configuration Because business rules and processes are fully abstracted in Kuali Student, there needs to be a way to capture a number of archetypal business rules as well as a number of edge case business rules which will become the basis for the reference implementation that will be configured and delivered with Kuali Student software. These rules and data abstractions can be captured through specific test cases. There are three kinds of test cases (use cases) that need to be captured for the reference implementation: Data test cases Business rules test cases Business process test cases 2.8 Develop approach for designing the concierge The concierge is a concept with many facets to it. It can be considered to be some or all of the following: A set of guiding principles for how we design the applications (such as ensuring we filter results sets) Business logic we incorporate into the design of every service (such as ensuring all services will run in what-if mode and logging usage statistics) Additional functionality that provides such things as logging certain data with data mining and reporting functionality. Appendix F - Application Development Approach June 18, 2007 Page F- 6

151 Appendix F - Application Development Approach The technical architecture phase of the project will be responsible for defining the concierge design principles and the standard concierge operations that should be built into every service. However the Application Development phases must concern itself with defining and developing any additional functionality that is desired by the user community. Because the Concierge functionality has the potential to be open-ended (similar to complex data reporting requirements), this aspect of the application development will need to be carefully managed in terms of scope and priorities. As with any of the Applications, the requirements for the Concierge functionality will be captured as Kuali features (through use cases and models) and reviewed against the other development priorities. 2.9 Develop detailed schedule of resources and activities The following activities will be performed: Develop a detailed work plan and work break down structure for the Year 1 activities: Application Architecture, Service Modeling and Contract Design Identify the roles, resources and skill sets required to complete all tasks Identify the size and composition of the teams Determine how each institution will organize their work to collect their specific business requirements. Identify checkpoints where external reviews of the project plans, artifacts and deliverables should be reviewed Develop communication and collaboration strategy At each institution: Identify institutional meetings and discussions Identify institutional wikis, websites, communication plans Determine how face-to-face meetings will be conducted and how information should be brought back to the institution from the face-to-face meetings Across institutions: Develop a process for collating information from each institution into the overall Kuali wiki and documentation Develop schedules for face-to-face meetings and discussions Determine how interactions with the Technical team will be conducted 2.11 Methodology review and signoff An external review of the methodology and approach will be conducted by industry experts who have experience in developing SOA architectures. Examples of such experts include: Thomas Erl IBM architects SUN architects The deliverable will be a 3-4 page critical report from one or more external reviewers. Appendix F - Application Development Approach June 18, 2007 Page F- 7

152 Appendix F - Application Development Approach 3 Application architecture During each phase of the Application Development process it is important to understand the purpose or objectives of the phase. These objectives will dictate the level of detail that will need to be gathered regarding business requirements or designed into the models. The purpose of the Application Architecture phase is to discover all the cross-cutting services within the student domain. We need to understand the connections and dependencies between the services in order to achieve our goals of service modularity and re-use. We also need to gather sufficient information to effectively partition the full student domain into sub-domains that can be worked on incrementally. Modeling (or diagramming) tools and techniques are used to document the system requirements so that they can be easily verified with the user community. These diagrams provide a consistent and efficient method to communicate across institutions either the Founders building the system or Adopters that may implement the system. In addition, the diagrams are used as inputs to the application architecture and design work that must be completed by the application development team. In this phase the high level business requirements are documented and a model of the Application Architecture is created. The following figure outlines the proposed major activities. The text following the figure provides a description of these activities and describes the deliverables produced. Appendix F - Application Development Approach June 18, 2007 Page F- 8

153 Appendix F - Application Development Approach 3.1 Create Conceptual Object Model During this activity the data/service architect works with the business analysts and the user community subject matter experts (SMEs) to develop a conceptual data model of the user requirements. It should cover the complete scope of the student system domain, however, particular emphasis should be placed on the core abstractions of Kuali Student including People, Block of time, Learning units, and Learning results. Deliverables from this activity include: 1. An Entity Relationship (ER) diagram that identifies major data entities (or objects), relationships, and cardinality. 2. A word document which provides descriptions of the ER diagram including o Entity definitions - a couple of sentences or a paragraph describing the entity. o Representative attributes may be specified if these help to define the entity o Where applicable, example instances of the entities (a thesaurus) which may be useful to define the entity This activity should be time boxed to ensure the full student domain is covered. The objective is not to identify all detailed entities, but rather to identify the high level conceptual entities or data subject areas. 3.2 Create Business Process Models Business analysts work with the SME s to define and record the student system processing requirements. Business process flows are documented for all of the application areas. It is important to capture the perspectives of all actors including faculty, staff and students for each process flow. Particular emphasis should be placed on the core abstractions of Kuali Student including People, Block of time, Learning units, and Learning results and how the business logic may be abstracted into rules engines. Deliverables from this activity include: 1. Business Process Models which show the process flows and the conditional branching. 2. Swim Lane Diagrams which illustrate which actors are performing which business functions within the process flow. This activity should be time boxed to ensure the full student domain is covered. The objective is not to create specific detailed business process flows for each institution, but rather to identify the high level business flows including stereotypical flows and edge case business flows that might test the models. 3.3 Gather Institutional Specific Requirements Each institution will gather whatever reference materials they deem necessary. May be documents previously prepared, may be newly created, or may just be in SME heads. It is up to each institution to decide format suites them best. It is recommended that it is fairly high level such as Use Cases or a list of desired features. These requirements should focus on functionality and business processes, not screen designs or presentation of materials. This is the raw material that will be used to define the Kuali Student specifications Appendix F - Application Development Approach June 18, 2007 Page F- 9

154 Appendix F - Application Development Approach These institutional specific requirements will be a key input to the implementation process for each institutions Each institution will need this raw material to do the verification check or gap analysis step below. 3.4 Collect and Document Use Cases Business analysts work with SME s to write up high level use cases for all of the application areas described in the Functional Scope Appendix. Use cases are captured during all phases of the project, but during this phase, the information gathered should be very high level. Use cases will become increasingly more detailed as the project advances through to software design, development and testing. A simple text document (MS Word) will be used to document use cases so that institutions beyond the Founding group are encouraged to contribute use cases. In addition, these use cases can be published on the Kuali Student website for general information. See section 8.5 for an example of a Use Case document. 3.5 Identify Test Cases for Reference Implementation Because the data models, business rules and processes are fully abstracted in Kuali Student, there needs to be a way to capture a number of archetypal business rules as well as a number of edge case business rules which will become the basis for the reference implementation that will be configured and delivered with Kuali Student software. These rules and data abstractions can be captured through specific test cases. These test cases will be selected from the superset of institutional use cases. This activity involves reviewing the set of institutional use cases and selecting a set of representative Test Cases for the Reference Implementation. There are three kinds of test cases that need to be identified for the reference implementation: Data test cases used to pre-populate the application with a number of data abstractions such as course, sessions, grades, etc. Business Rules test cases used to illustrate how processing such things as degree rules or admission rules may be governed. Orchestration (business process) test cases used to illustrate a business process flow for things like registration, self admission or promotion. 3.6 Map Institutional Requirements to Kuali Features During this activity, each institution performs a gap analysis between their specific institutional requirements and the Kuali features (product requirements) that have been documented via the use cases, the conceptual data model, and the business process models. When the gaps have been identified, the Founders will meet to determine if any additional features should be added to the Kuali Student product. The assessment will depend on the scope of the changes and the group priorities. In some cases, new features may be added. In other cases, where an institution has a very specialized need or the scope is too large, the gap will remain and will become an institutional implementation issue. When the gap analysis is complete, the Functional Steering Committee will sign off on the Kuali Student Conceptual design as set out by the business models Appendix F - Application Development Approach June 18, 2007 Page F- 10

155 Appendix F - Application Development Approach 3.7 Identify Service Candidates During this activity the business analysts and the service architect work together to identify the candidate services. They use as inputs the Conceptual Data Models and Business Process Models produced during the first 2 steps. The objective is to identify services that are modular, loosely coupled, and will be re-usable. This activity should be time boxed to ensure the full student domain is covered. Services are identified and described at a high level. No attempt is made to gather the detailed information that will be required to design the service contracts. The deliverables from this phase include: 1. A service stack diagram showing the services laid out in the SOA layers (see section 8.7 for an example.) 2. A Service Description Document ( a supporting word document) that describes each of the services including: o Title o 2-3 line description o Representative operations that the service performs 3.8 Partition Services into Applications and Domains During this activity, the Service Candidates that were identified in the previous step are partitioned into domains or applications. The objective of the partitioning is to: Break up the development effort into manageable units of work. These units of work can be package for release in a phased manner. To provide plug-and-play modules for institutions to choose from. This will facilitate migration (implementation / deployment) in logical units. To understand the dependencies and connections (data and processes) between the services so we can propose reference business processes (orchestrations) that may often be grouped together. The deliverables from this activity are a set of mappings or matrices called Service X-Reference Diagrams (see section 8.8 for an example): 1. Service/application direct-call matrix 2. Service/service matrix 3. Service/application matrix (derived from #1 and #2) The final deliverable is a list of all of the services that must be developed and released as a bundle for each application. 3.9 Validate Application Architecture against Concierge Design Principles During this activity, the Application Architecture is reviewed against the Concierge design principles defined in partnership with the Technical Architecture team. In addition, the use cases that have been identified as cases where Business Intelligence might be applied (and therefore classified as concierge use cases) are reviewed in the context of the Application Architecture. If any part of the architecture will not satisfy the concierge design principles or the concierge use cases, the architecture is adjusted accordingly. Appendix F - Application Development Approach June 18, 2007 Page F- 11

156 Appendix F - Application Development Approach 3.10 External review and signoff The final step in the Application Architecture phase is a checkpoint before proceeding to the next phase. The following activities will be performed: External review of the Application Architecture (commercial vendor or industry expert) User signoff (Functional Steering Committee) Technical signoff (Technical Steering Committee) The deliverable will be a 3-4 page critical report from one or more external reviewers. Appendix F - Application Development Approach June 18, 2007 Page F- 12

157 Appendix F - Application Development Approach 4 Service Modeling The purpose of the Service Modeling phase is to refine the list of Service Candidates and clearly define what the service does - what data it manipulates, what operations it performs and what messages it processes. However, during the Service Modeling phase, the definitions of the services are fluid they change frequently as more and more information is gathered. In order to avoid a lot of re-work, the information that is gathered is maintained at a medium level of detail. The service definitions that result from this phase will be used as inputs to the Service Contract Design Phase. Once the team moves on to the Service contract design phase, which involves a great deal of very detailed and specific work, it is important that the service definitions do not shift dramatically. For this reason a user signoff checkpoint is placed at the end of this phase. Modeling (or diagramming) tools and techniques are used to document the system requirements so that they can be easily verified with the user community. These diagrams provide a consistent and efficient method to communicate across institutions either the Founders building the system or Adopters that may implement the system. In addition, the diagrams are used as inputs to the service contract design work that must be completed by the application development team. The following figure outlines the proposed major activities. The text following the figure provides a description of these activities and describes the deliverables produced. Appendix F - Application Development Approach June 18, 2007 Page F- 13

158 Appendix F - Application Development Approach 4.1 Collect and Extend Use Cases Business analysts work with SME s to write up use cases for the relevant application area or domain under consideration. Use cases are captured during all phases of the project, but will become increasingly more detailed as the project advances through to software design, development and testing. During this phase, the information gathered should be at a medium level of detail and should include the following: A fairly detailed account of the use case, including the operations and business logic Definitions of all actors that are involved in the business process and what their responsibilities are Definition of any pre-conditions or validations that are required Classification of the use case. For example if this use case is relevant to the concierge or if it will be used as one of the test cases for the reference implementation A simple text document (MS Word) will be used to document use cases so that institutions beyond the Founding group are encouraged to contribute use cases. In addition, these use cases can be published on the Kuali Student website for general information. See section 8.5 for an example of a Use Case document. 4.2 Develop and Extend Test Cases for Reference Implementation Because data models, business rules and processes are fully abstracted in Kuali Student, there needs to be a way to capture a number of archetypal business rules as well as a number of edge case business rules which will become the basis for the reference implementation that will be configured and delivered with Kuali Student software. These rules and data abstractions can be captured through specific test cases. These test cases will be selected from the superset of institutional use cases. During this activity, the test cases selected for the reference implementation are reviewed. Additional test cases may be selected based on the new information that is gathered during the Service Modeling phase, or the existing test cases may be expanded to include a more detailed description of the use case. 4.3 Define Services - Iteration 1 For each service candidate that has been defined as part of the current domain (Curriculum Management for release 1), the business analysts and the service architect will work with the SME to prepare the Service Description Document. The following information will be gathered: service description 2-3 sentences service classification specify the layer in the SOA diagram o user interface (UI) service o controller service: mapping request to orchestration o orchestration (process / workflow) service o business - process agnostic service o infrastructure (application) service Object Model (class diagram) at high level: object names, descriptions & relationships description of message(s) textual description of the message full list of operations define responsibilities for actions (consumer or provider) a list of the consumers Appendix F - Application Development Approach June 18, 2007 Page F- 14

159 Appendix F - Application Development Approach This first iteration of the service modeling will be time-boxed to ensure the full extent of the current domain is covered. Care must be taken not to gather too much detail in any one area at the expense of fully completing the first iteration. Each subsequent pass and development phase will gather more detail as appropriate. 4.4 Validate Service Definitions Iteration 1 During this activity, the service definitions will be reviewed and validated against the following tests. Changes resulting from these validations will be incorporated into the Service Definitions. Does the service have the appropriate functional granularity (as defined by the Technical Architecture team)? Are any modifications required to the overall architecture diagrams and structure? Is the domain partitioning still correct? In particular the domain under construction (Curriculum Development in the first release) needs to be re-evaluated to identify what services are required from the other domains to support it. Are the user requirements, as expressed in the use cases, satisfied? In particular, are the reference implementation test cases satisfied? Do the service definitions follow internal consistency standards (e.g., naming standards)? Do the identified test cases for the reference implementation need to be updated> Do the service definitions conform to the concierge design principles and concierge service stereotypes as defined by the Technical Architecture team? 4.5 Define Services Iteration 2 During the second iteration of Service Modeling, the Service Definitions are refined and more detail is added: the Object Model is refined and more detail added the list of operations (methods) are expanded and all errors and return conditions are described description of responsibilities are refined and updated the partition diagram (Service X-Reference Diagram) is updated service policies are defined: o security policies o service availability requirements o performance requirements, etc. During this iteration the business analyst and service architect will also create Service Interaction Diagrams (sequence diagrams) which illustrate the expected behaviors and orchestration of composed services. These diagrams show how services are expected to be orchestrated to deliver end-to-end business processes. The Service Interaction Diagrams need to reflect both the perspective of the Provider (of the service) and the perspective of the Consumer (of the service). See section 8.10 for an example of a Service Interaction Diagram. It is useful to keep the following definitions in mind when discussing services that call other services: Service Composition how one service calls other services to achieve a specific result. Service composition is not configurable - it is built into the program logic. Appendix F - Application Development Approach June 18, 2007 Page F- 15

160 Appendix F - Application Development Approach Service Orchestration how a high level service puts together other services to complete a business process. This is configurable through a Java program, through BPEL and/or through workflow. 4.6 Validate Service Definitions Iteration 2 During this activity, the service definitions will be reviewed and validated against the following tests. Changes resulting from these validations will be incorporated into the Service Definitions. Does the service have the appropriate functional granularity (as defined by the Technical Architecture team)? Is the domain partitioning still correct? Are any modifications required to the overall architecture diagrams and structure? Are the user requirements, as expressed in the use cases, satisfied? In particular, are the reference implementation test cases satisfied? Do the service definitions follow internal consistency standards (e.g., naming standards)? Do the identified test cases for the reference implementation need to be updated> Do the service definitions conform to the concierge design principles and concierge service stereotypes as defined by the Technical Architecture team? Are the definitions of objects from the object models consistent across all of the services During this activity, we also compare the service definitions to the functionality (capabilities) of the legacy systems from each institution to validate the following: Is there any functionality that we ve inadvertently left out but want to implement? Is there functionality that we ve left out and don t intend to implement, so that institutions who want that functionality must implement themselves? 4.7 User Interface Design Early in the program, during the first Service Modeling phase, the screen design standards and style templates will be defined for the system. These User Interface (UI) Style templates may be developed in conjunction with a number of other projects such as the Kuali Foundation or the FLUID project. Opportunities for leveraging the work of these other project will be actively pursued. Where joint development is not possible or does not fit, the UI Style templates will be developed specifically for Kuali Student. The deliverables from this phase are Style Template design specifications (not code) including such things as: Headers, footers, help Screen layouts, label dictionary Screen behavior Screen templates for inquiry, update, tables, etc. Style templates should consider different types of audiences or categories of users such as: o Different perspectives (faculty, students, staff) o Persona descriptions (computer lover, computer hater) Appendix F - Application Development Approach June 18, 2007 Page F- 16

161 Appendix F - Application Development Approach This activity will also include the development of screen mock-ups for re-usable components that can be used to help functional users understand and verify the service model. The mockups would give examples of what may be on the screen showing which information may be presented where. 4.8 Signoff The final step in the Service Modeling phase is a checkpoint before proceeding to the Service Contract Design phase. This is the inflection point between the fairly fluid service modeling process and the less fluid contract design phase. The service definitions that result from this phase will be used as inputs to the Service Contract Design Phase. Once the team moves on to the Service contract design phase, which involves a great deal of very detailed and specific work, it is important that the service definitions do not shift dramatically. For this reason signoff is required by both the functional (users) and the technical participants at each institution. Appendix F - Application Development Approach June 18, 2007 Page F- 17

162 Appendix F - Application Development Approach 5 Service Contract Design The purpose of the Service Contract Design phase is to take the list of Service Definitions and further refine them by clearly defining how the service does its work. Complete technical specifications for the Service Contract are defined. The service contract specifications that result from this phase will be published to the community and may be used by a very wide audience. It is hoped that the community will use these service contract specifications to develop student system functionality beyond the scope of this program that will enhance the total Kuali Student product offering. As a result, the information that is gathered and used to create the contract specifications is very detailed. It is important that there be very little change to the service contract specifications after they are published. The following diagram outlines the proposed major activities. The text following the diagram provides a description of these activities and describes the deliverables produced. Appendix F - Application Development Approach June 18, 2007 Page F- 18

163 Appendix F - Application Development Approach 5.1 Collect and Document Use Cases Business analysts work with SME s to refine and enhance the detailed use cases for the relevant application area or domain under consideration. Use cases are captured during all phases of the project, but will become increasingly more detailed as the project advances through to software design, development and testing. During this phase, the information gathered should be at a low level of detail and should include the following: A very detailed account of the use case, including the operations and business logic Definitions of all actors that are involved in the business process and what their responsibilities are Definition of any pre-conditions or validations that are required Classification of the use case. For example if this use case is relevant to the concierge or if it will be used as one of the test cases for the reference implementation A simple text document (MS Word) will be used to document use cases so that institutions beyond the Founding group are encouraged to contribute use cases. In addition, these use cases can be published on the Kuali Student website for general information. See section 8.5 for an example of a Use Case document. 5.2 Develop and Extend Test Cases for Reference Implementation Because the data model, business rules and processes are fully abstracted in Kuali Student, there needs to be a way to capture a number of archetypal business rules as well as a number of edge case business rules which will become the basis for the reference implementation that will be configured and delivered with Kuali Student software. These rules and data abstractions can be captured through specific test cases. These test cases will be selected from the superset of institutional use cases. During this activity, the test cases selected for the reference implementation are reviewed. Additional test cases may be selected based on the new information that is gathered during the Service Contract Design phase, or the existing test cases may be expanded to include a more detailed description of the use case. 5.3 Service Contract Design Iteration 1 During this activity the service architect works with the applications developers to start the specification of the service contract. The user subject matter experts will be consulted for clarification and extension of the business requirements. The Service Contract Design specification is a structured document such as Excel or UML that will generate Java interfaces. It includes the following information: (see section 8.11 for a template) full definition or specification of the message structure (method parameters) o pre-conditions for service execution defined by the input message definition and specification of all error codes o error conditions o exception messages (returns) recommended approach to expected institutional exceptions Appendix F - Application Development Approach June 18, 2007 Page F- 19

164 Appendix F - Application Development Approach 5.4 Validate Service Contract Design Iteration 1 During this activity, the service contract design specifications will be reviewed and validated against the following tests. Changes resulting from these validations will be incorporated into the Service Contract specifications. Does the service have the appropriate functional granularity (as defined by the Technical Architecture team)? Is the domain partitioning still correct? Are any modifications required to the overall architecture diagrams and structure? Are the user requirements, as expressed in the use cases, satisfied? In particular, are the reference implementation test cases satisfied? Do the service definitions follow internal consistency standards (e.g., naming standards)? Do the identified test cases for the reference implementation need to be updated? Do the service definitions conform to the concierge design principles and concierge service stereotypes as defined by the Technical Architecture team? Are the definitions of objects from the object models consistent across all of the services? Validate transaction integrity considerations During this activity, we also compare the service contract to the institutional legacy system capability/functionality to validate the following: Is there any functionality that we ve inadvertently left out but want to implement? Is there functionality that we ve left out and don t intend to implement, so that institutions who want that functionality must implement themselves? 5.5 Service Contract Design Iteration 2 During this activity the service architect works with the application developers to complete the full specification of the service contract. The user subject matter experts will be consulted for clarification and extension of the business requirements. The following activities will be performed: The Service Contract is refined and final details of the specification are completed. JUnit test are defined that can be used for testing The specifications are transformed into one or both of the following: o well annotated WSDL o Java interface w/ JavaDoc) An implementation guide is prepared for the service contract in preparation for publication A service registry is created that describes and documents the consumers of each service 5.6 Validate Service Contract Design Iteration 2 During this step, the application developers will work closely with the technical architecture team to conduct a proof of concept by implementing a number of selected services stubs. The selection of the services to be tested will be made in consultation with the technical architecture committee and the user community. The implemented services will NOT be fully functioning Appendix F - Application Development Approach June 18, 2007 Page F- 20

165 Appendix F - Application Development Approach services, but rather a first simple iteration of the service development that will test the concepts. The following will be tested: Are the services at the appropriate level of granularity? How many levels of composition are required and how will this impact performance? Have we made the correct trade-offs between re-use and modularity? Exercise the dependencies between services Validate against (or map to) industry standards - to the extent Kuali Student has decided to be constrained by those standards Validate against user requirements in particular can we demonstrate how the data abstractions, the rules driven business logic, and the service orchestrations can implement different institutional process requirements? Validate the original service application architecture Perform JUnit tests against the service stubs 5.7 Develop User Interface Re-Usable Components During this step, the application developers work to develop re-usable UI components such as widgets, exchangeable skins, and forms. These re-usable UI components may be developed in conjunction with other projects such as the Kuali Foundation or the Fluid project, or they may be purchased open source products: o Exchangable skins (Sitemesh - ) o Widgets and forms from open-source projects (MyFaces - ; Exadel - ) o Fluid ( ) Note that product selection of the UI technology stack will be conducted by the Technical team during the Technical Architecture Phase. This activity would also include the testing of mock-ups of re-usable components. These mockups would not be the final coded products, but could be used to help functional users understand and verify the service contract design. 5.8 Service Contract Design Signoff The final step in the Service Contract Design phase is a checkpoint of sign-off before publishing the Service Contracts to the community. Although it is to be expected that in the early stages of the program the service contracts may require some modifications, the objective is to keep these to a minimum. Large changes to the contracts will be very disruptive to the developers. This review and signoff process will provide a quality and consistency check before proceeding to the development phase. Appendix F - Application Development Approach June 18, 2007 Page F- 21

166 Appendix F - Application Development Approach 6 Software Design & Development The purpose of the Software Design & Development phase is to finalize the design and development of the Kuali Student application or domain currently under construction (Curriculum Development for Release 1). This includes the development of all services, user interface components, and system documentation required to release the product. It also includes the configuration of the reference implementation including the data abstractions, the business logic rules, and the orchestrated services that will form the end-to-end business process. The Kuali Student Program will use Agile Development techniques during the software development and design phase. Agile development techniques will allow us to focus on delivering software that meets each institution s needs with the highest possible quality, in the least possible time, and at the lowest possible cost. Agile development techniques involves a series of iterative and incremental design and development cycles, each one time boxed to achieve a specific deliverable. Members of the user community will be active participants on the development teams, providing valuable input into the planning, design, and testing of the system. The planning, analysis and design will take place throughout the projects to ensure that development will be able to adapt to changes in requirements and/or scope. Frequent feedback loops and test driven development will ensure that a high level of quality is maintained throughout the development of the system. The unique nature of the Kuali Student will rely heavily on the agile concept of Learn, Try, Reflect and Adapt to ensure the ongoing success of this project. The application developers will be organized into 2 work streams for the design and development phase. One will focus on the User Interface (UI) or user facing components and the other will focus on the development of the Services. Although these two teams must work closely together, this division of focus and work assignments will remove the temptation to hardwire the UI to the services. The following figure outlines the proposed major activities during the Design and Development phase. The text following the figure provides a description of these activities and describes the deliverables produced. Appendix F - Application Development Approach June 18, 2007 Page F- 22

167 Appendix F - Application Development Approach 6.1 Design and Development of User Facing (UI) Components As with the previous phases, during this phase the application developers work with the user SME s to refine and enhance the detailed use cases for the relevant application area or domain under consideration. The final details of how the application will function are added here. Details are added to the use cases that can be used as specific test cases during the software development phase. Particular attention is paid to the Reference Test Cases that have been identified during the earlier phases of the program UI Design with Users During this step, the application developers work with the users to design screen layouts and screen navigation. Mock ups are prepared to illustrate the end product. Inputs to this design process include: The UI style templates developed during the service modeling phase The re-usable UI components (widgets, skins, forms) service design phase The use cases developed during all previous phases. Appendix F - Application Development Approach June 18, 2007 Page F- 23

168 Appendix F - Application Development Approach Software Design of UI Components During this activity, the application developers take the screen mockups developed with the users and complete the software design specifications for the user facing components: portlets, servlets, JSPs. Deliverables include: Class diagrams Sequence diagrams Use cases updated as design continues Software Design of Business Controller During this activity, the application developers complete the software design specifications for the business controller java components. Deliverables include: Class diagrams Sequence Diagrams Develop Web Application Components During this activity, the application developers code and test the web application components of the software. When the developers have completed their unit testing, they will work with the users to test the results against the Use Cases and Test cases that were developed in previous phases. The result of this development is.war files including: JSPs/HTML/CSS/JS Portlets Servlets Java objects Develop Business Controller Components During this activity, the application developers code and test the business controller java components with or without services stubs. The result is a.jar file. 6.2 Design and Development of Services Software Design of Services During this step, the application developers complete the software design specifications for the services. Inputs to this design process include the service contract and the services integration diagrams (sequence diagram and services x-reference matrix). The application developers will consider the design from the perspective of both the producer and the consumer of the service. They will complete the design for atomic services, composed (hard-wired) services and java components. Deliverables include: Class diagrams (object models) Sequence Diagrams Database design Appendix F - Application Development Approach June 18, 2007 Page F- 24

169 Appendix F - Application Development Approach Service Orchestration Design During this step, the application developers complete the software design specifications for the orchestrated services. Inputs to this design process include the service contract and the services integration diagrams (sequence diagram and services x-reference matrix) and the reference implementation Test Cases. Deliverables include service orchestration design for the reference implementation: Design workflow Exception handling Roll back mechanism (transactional) Code and Test Services During this activity, the application developers code and test the services software. Inputs to this process include: The stereotypes and coding standards developed by the Technical Architecture team The use cases developed during all previous phases. When the developers have completed their unit testing, they will work with the users to test the results against the Use Cases and Test cases that were developed in previous phases. The results of this development process are: The database implementation (a file with ddl scripts) One web service archive (a.aar file) per service either one service client.jar file per service or, one client.jar file for all services. Note - these.jar files may have service stubs or not Configure and Test Orchestrated Services During this activity the application developers work with the users to configure and test the orchestrated services that have been identified for the reference implementation. The Reference Implementation Test Cases are used to validate that the full end-to-end business processes can be implemented in the system. 6.3 Prepare Documentation Package During this activity, the application developers work to complete the system documentation that will be required to release the final product. Documentation deliverables include: Install guides System overview documents Basic implementation and configuration guides o Note that the level of detail for these implantation guides will be fairly high level. It is anticipated that implementing institutions and adopters of the software will contribute more detailed implementation documents after they complete their implementation process. Appendix F - Application Development Approach June 18, 2007 Page F- 25

170 Appendix F - Application Development Approach 7 Product Release and Implementation Support During this phase of the program, the Kuali Student Software will be packaged up and released for implementation. Product support will be provided by the Kuali Student developers to the founding institutions who are implementing the software at the time of release (at least one). At the same time, the Kuali Student developers will work with the long term sustainment organization (possibly a vendor) to transition the support activities to that organization. 7.1 Package and Release Software During this step, the software is bundled into a software release package and is made available for download on the Kuali Student download server. Initially the download will only be available to Founders and Partners, but eventually it will be available to the public. This package will include all of the required components: WAR files AAR files JAR files Build scripts Install guides System documentation Implementation guides Etc. In addition, the reference implementation of the software will be moved into the Kuali Student production instance (PROD) and made available to the community as part of Kuali Student Test Drive. Kuali Student Test Drive will be available on a public website for potential adopters to demo the software. As a final step, the WSDL / Schema for the Kuali Student Service Contracts for this release will be published on the Kuali Student website as Kuali certified. Partner and Adopter institutions will be encouraged to use the service contracts to expand or enhance the Kuali Student software. Information will also be published on procedures for incorporating software contributions (bug fixes, enhancements, or new application modules) into the Kuali Student code base. Appendix F - Application Development Approach June 18, 2007 Page F- 26

171 Appendix F - Application Development Approach 7.2 Support Implementation Projects During this step, the Software Release Package is downloaded by the Founder and Partner institutions for their implementation efforts. Note that the Founder and Partner implementation projects may already have been working with early versions of the software, but this package will be required for their final software configuration, integration and testing. The Kuali Student development team will work with the institutional implementation teams to resolve any issues and incorporate fixes back into the base product. At the same time, the team will start to work with the long term support organization to transition product knowledge. At the end of this step, the implementing institutions will Go-Live into production with Kuali Student. During this period, there will be a pause in Kuali Student software development as the team s efforts will be focused on support. However, the Subject Matter Experts and the Business Analysts may continue to work on the next phase of the service modeling and contract design. 7.3 Production Support and Transition to Support Organization As soon as the first institution goes into production with Kuali Student all development work on the software will pause while the project team provides production support to the implementing institution. The Kuali Student development team will resolve any software issues and incorporate fixes back into the base product. At the same time, the team will continue to work with the long term support organization to transition product knowledge. The goal is to have the support organization take over product support by the end of this phase. At the same time, the Kuali Student Architects and the project managers will work to get ready for the development of the next application modules. They will: Adjust project plans based on experience to-date Adjust architectural documents if required Update the Developers workbench if required Appendix F - Application Development Approach June 18, 2007 Page F- 27

172 Appendix F - Application Development Approach 8 Sample Documentation Templates and Formats This following section provides diagram formats and templates for artifacts that will be created during the Application Development process. 8.1 Entity Relationship Diagrams A high level model of the entire student domain can be captured in a single conceptual object model. Here is an example of an Entity Relationship diagram that illustrates the Learning Units and Learning Results objects and their relationships. (example only!) Appendix F - Application Development Approach June 18, 2007 Page F- 28

173 Appendix F - Application Development Approach 8.2 Entity Definitions Here is an example of an Entity Definition template and the description for Learning Units. Entity Name: Learning Unit Entity Description: A learning unit is any learning-related activity that needs to be tracked by the institution or the learner. Learning units range from very general (a degree program) to very specific (a class assignment). More general learning units are composed of more specific learning units, and a single Person may participate in many learning units. Asdf asdf Examples of Instances of the Entity: Overall goals: The learner's general, long-term goals o Degree program o Major or minor Learning activities: Usually time-limited; usually designed to move the learner toward their overall goals o Course, seminar, workshop o Semester, term o Volunteer activity, service o Residency Learning components: Contribute toward completing a learning activity o Assignment, paper o Exam o Lab Collaborations o Discussion group, reading group o Conference Representative Attributes Identifier Name Common identifier Description Start date Duration Time limit End date Attribute Description A unique identifier (a SKU) A name A cosmetic identifier (such as a traditional course number) A short description of the Learning unit Appendix F - Application Development Approach June 18, 2007 Page F- 29

174 Appendix F - Application Development Approach 8.3 Business Process Models Here is an example of a high level activity diagram for the Evaluate Academic Progression process: Appendix F - Application Development Approach June 18, 2007 Page F- 30

175 Appendix F - Application Development Approach 8.4 Swim Lane Diagram Here is an example of a swim lane diagram for On-line Subject Evaluation: Appendix F - Application Development Approach June 18, 2007 Page F- 31

176 Appendix F - Application Development Approach 8.5 Use Cases Here is an example of a Use Case for Update Payment Schedule: UC Update Payment Schedule Business Domain Student Financials Description Update an existing payment schedule as a result of some order activity, i.e. add, delete or update of one or more items. Actors Financial Administration Clerk. Pre Condition 1. User has been authenticated 2. Customer Account object has been loaded 3. Customer Account is up to date, i.e. calc has been executed if necessary 4. Payment schedule already exists Post Condition After schedule is updated, payments should be re-applied. See use case, Apply Payment Implementation Issues Use QR to determine Payment Schedule? Basic Flow of Events 1. If this update is as a result of a payment method change see Alternate Flow Calculate new total for term from order items. 3. Calculate old total for term from existing schedule items 4. If totals for each term are the same, exit. 5. If new total > old total for term, update payment schedule to add extra amount a) If payment method = payroll deduction, see Alternate Flow 2. b) Otherwise find future schedule items in term using actual due date (this may include deferred schedule items) c) If one exists, add amount to this schedule item. d) If > 1 exists, divide extra amount by number of remaining schedule items and add this amount to each e) If none exist, create extra installment due 7 days after start of the next month for the amount of the difference 6. If new total < old total for term, update payment schedule to remove amount. Appendix F - Application Development Approach June 18, 2007 Page F- 32

177 Appendix F - Application Development Approach a) If payment method = payroll deduction, see Alternate Flow 3 b) Starting at last future installment for term, subtract amount until no difference amount left. Delete any installments where amount due is now zero. Alternative Flow of Events 1. If payment method has changed, e.g. student is no longer an employee and no longer paying through payroll deduction, delete existing schedule and create a new schedule. See Create Schedule use case. 2. If amount due has increased for a payroll deduction payment schedule, a) divide additional amount by number of future installments b) add this divided amount to each of the future installments 3. If amount due has decreased for a payroll deduction payment schedule, a) Determine no of future installments b) If future amount due > difference, divide difference by count of future installments and subtract this amount from each installment c) If future amount < = difference start at the last future installment and subtract Exceptional Flow of Events None. Included Use Cases Create Payment Schedule Design Questions and Issues: None. Test Cases: TBD. Implementation Questions and Issues: None. Appendix F - Application Development Approach June 18, 2007 Page F- 33

178 Appendix F - Application Development Approach 8.6 Service Description Template The document below is a sample Service Definition. It is intended to be a simple, unstructured way of capturing information about the service. Note that it is combined with Class Diagrams and Service Interaction (sequence) Diagrams and Service X-reference Diagram (see below) to get the full Service Definition. Service Name: Service Description: Academic Decision Service The Academic Decision Service is a business process agnostic service. It contains a variety of operations to evaluate a student s academic record. It returns an Evaluation Result which can then be consulted to: Determine whether the evaluation was successful Which parts of the academic record were used in the evaluation Service Classification: Business Process Agnostic Services Operations Inputs Outputs evaluateacademicrecord Rule ID Evaluation Result Academic Record evaluatetestscores Rule ID Academic Record Evaluation Result evaluatenonacademicrecord Rule ID Evaluation Result Non Academic Record Responsibilities for Actions List of Consumers Admissions processes (evaluating high-school transcripts and test scores) Degree audit processes (evaluating the academic record) End of term/session evaluation (evaluating the academic record) Awards processes (evaluating the academic record for merit based awards) Security Policy The evaluations are part of the public policies of the institution. This service can be exposed in a what-if mode on a public website. There are no special security policies. Availability Requirements Must be available 24/7. Processes that orchestrate inbound EDI transcripts and evaluation must always have access to this service Performance Requirements Should be able to complete 4000 evaluations an hour. That means an online evaluation can be conducted in under 2 seconds and batch evaluations for an entire institution can be completed overnight. Appendix F - Application Development Approach June 18, 2007 Page F- 34

179 Appendix F - Application Development Approach 8.7 Service Stack Diagram Appendix F - Application Development Approach June 18, 2007 Page F- 35

180 Appendix F - Application Development Approach 8.8 Service X-Reference Diagram There are 3 types of x-reference diagram illustrated below: 1. Service / application direct-call matrix Maintain person Customer contact application Maintain group Create Commun relations icate hip Develop template Curriculum Develop learning unit Make learning unit available Assess learning unit Apply Acknoledge Admissions Maintain Maintain non- Transfer academic history academic history credit Evaluate Leaning unit template service Add template Update template Learning Unit Service Add learning unit Update learning unit Publish learning unit Schedule learning unit Check availability Identity service create Identity addattributes addcontact uodatecontact Contact service addaddress add addtelephoneno Workflow service createflow updateflow executeflow notify Data configuration service createdataelement addattribute setattributevalue getelement Rules definition service Create rule Update rule Delete rule 2. Service/service matrix 3. Service application derived matrix Appendix F - Application Development Approach June 18, 2007 Page F- 36

181 Appendix F - Application Development Approach 8.9 Object Model (Class Diagram) The following is an example of an Object Model for Learning Units: Appendix F - Application Development Approach June 18, 2007 Page F- 37