East Carolina University Onestop

1. East Carolina University Onestop Leveraging Enterprise Portal TechnologySteven Forehand, Manager, NTDG forehands@mail.ecu.edu

2. Who is East Carolina University? • Founded in 1907 • Located in Greenville, North Carolina (about 80 miles south-east of Raleigh) • Approximately 22,000 enrolled students • Approximately 3,500 staff members. • Offers approximately 100 Bachelor degree programs, 18 Masters degree programs, and 13 doctoral programs • Visit http://www.ecu.edu for more.

3. Who am I? • Steven Forehand • Current Manager of the New Technologies Development Group… more later… • Graduated from East Carolina University with a B.S. in Computer Science • 9+ years of software development experience • Been employed by ECU since 1997.

4. Who is the NTDG? • New Technologies Development Group • Resides with Software Development Services • Part of ECU’s Information Technology and Computing Services (ITCS) • Consists of 3 distinct divisions with 14 total employees… more later… • Primarily responsible for the investigation, development and implementation of “newer” technologies

5. NTDG Divisions • Investigation and Integration – 3 dedicated staff, development of Onestop portal • Application Development – 6 dedicated staff, development of applications • Web Initiatives and QA – 4 dedicated staff, main ECU website, usability and interface, ADA, Quality Assurance • Each division has a project coordinator

6. NTDG in a “nutshell” The NTDG is mainly responsible for…. • E-business/e-services applications • E-commerce • Portal infrastructure development • Student-centered and administrative web applications • Design, development and implementation of internet/intranet applications • Investigation of new technologies

7. What is a “Onestop”? • Traditional Portal functionality • Addition of managed, secure software development environment • Offers services for entire campus community (i.e. students, staff, advisers, instructors, etc) • Designed and developed using Macromedia Coldfusion • For lack of better term… “Campus Portal”

8. Why Macromedia Coldfusion? • Minimal costs • CFML syntax is tag-based • No manual compile process for testing • Source can be encrypted • Short learning curve • Allows code reuse and extensibility • Custom tags (CFML and java based) • User defined functions (UDF) • External object calls • Java • C++

9. Why Macromedia Coldfusion? • Easy to manage application and session data within applications • IDE ColdFusion Studio and now Dreamweaver are very user friendly • File Management (Visual SourceSafe) from within ColdFusion Studio • Easy server administration • Simple database connectivity • Job/template scheduling • Clustering capability

10. Why Macromedia Coldfusion? • Large developer community provided excellent support • Coding methodologies (fusebox) • Custom tags and code snippets • Answers to the rare question • Most legacy developers find syntax and concepts easy to understand

11. ECU Onestop Development • Developed initially by a team of dedicated, talented software developers • Provides service to the entire campus (ie students, faculty, staff) • First University “portal” within the N.C. University system • Was a lot of fun!

12. Develop? Why not purchase? • Evaluated packaged and open-source solutions (i.e. Uportal) • Others did not offer the “entire” package • Functionality was somewhat limited • Some processes were unnecessarily difficult (i.e. channel development) • Had a talented staff… could do it ourselves… and better.

13. Is the Onestop successful? • Used by over 98% of students • Used by over 94% of staff and faculty • Over 15,000,000 logins by 82,000 unique visitors since 2000 • Strong campus support • Recently selected over Sungard/SCT Luminis … more later… • Nearly zero maintenance • Requires little funding

14. SCT Luminis vs ECU Onestop • ECU recently purchased Sungard/SCT Banner Enterprise solution. • After analysis, Onestop chosen over SCT Luminis as campus “portal” • ECU Onestop 100% compatible with SCT Banner (including self-service applications) • ZERO functionality loss with selection of Onestop over Luminis… • Onestop better financial decision (ie maintenace, support, etc) • Onestop will work with ANY campus’ SCT Banner implementation (or other ERP solution)

15. Security • Servers use 128-bit SSL security for HTTP requests • ECU Onestop requires login by University userid and passphrase • Servers located behind several firewalls • Hardware clustering solution offers better performance and security • Datasources are located behind firewall • To date, no major hacks

16. ECU Onestop Login Process • Go to http://onestop.ecu.edu • Login using University email userid and passphrase • Login verified • Roles and permissions are established • Session created • Access granted! Have fun

17. Roles and Group Permissions • Roles and permissions are determined dynamically according to University databases • Can be member of large groups (i.e. student, employee, adviser, instructor, etc) • Can be member of small group (i.e. specific department, job class, student class, etc) • Permissions can be given to an individual

18. Roles and Group Permissions • Content and applications based on roles or combination of roles • Dynamic roles allow “instant” access to applications and content • Dynamic roles require very little maintenance • Allows creation of traditional, maintained groups.

19. ECU Onestop “Tabs” • Sections of the portal content are accessed through “tabs” • Each tab contains user specific and customizable content • Not all tabs are available to all users

20. ECU Onestop “Tabs” • Home – first tab encountered, channelized content with login area • My Page – traditional “portal” with channelized, personal content • Tools – personalized applications available to users • Profile – “snapshot” of current user • Community – threaded discussion, chat • Email – one click access to University email system

21. Have it your way • Look and feel entirely customized by user • Themes change the look (graphics) of all content including individual applications • My Page channels can be selected and arranged • Channels can be “forced” • Again, content and applications available are based on “roles”

22. Applications Available A sample of typical “student” applications or “tools”…. • Course grades and schedules • Course catalogs • Course registration • Tuition payments • Parking Citations and Appeals (interacts with T2 solution) • Various surveys (i.e. DE Survey, Adviser Survey, etc) • More

23. Applications Available A sample of typical applications offered to advisers, instructors, employees, etc. • Advisee listing – including contact information and schedules • Course rosters – including contact information and schedules • Service Request • View pay check information • Faculty and Staff training • Publications database • Academic difficulty reports • More

24. Applications Available A sample of typical applications offered to all (or most) users… • Employment opportunities • Campus Directory / People Search • Register vehicle and purchase permit • Majors and degrees • Course catalog • Graduation and honors listing

25. Application Development • “Portal” and internal applications written in CFML. • APIs provided for formatting, data elements, and business logic. • “Portal” and internal applications written using Fusebox development methodology • Rapid Application Development

26. Questions to ask ourselves • What do others have that we want? • What do they not have that we want? • What technologies are available for doing what we want? • Is it feasible to make this work within our environment? • Is it worth the effort?

27. What’s missing? Changes? • Dynamic content formatting • Currently, each channel or app is responsible for display • Theme settings passed to apps for formatting • Multiple display types established at the application level • PDA • cell phones • Consistency is hard to maintain

28. What’s missing? Changes? • Reusable code • Currently, some reusable code is stored in CF Custom Tags and UDFs • Not efficient • Duplicate code in various channels / apps is difficult to maintain • Adaptability to other channel standards • Advanced Proxy capability

29. What’s missing? Changes? • Single Sign-On capability • Interaction with JMS (i.e. SCT LDI) • Greater use of web services to syndicate data for external and internal sites. • Portal Standards • Investigating three • JSR 168 Portlet Spec • JA-SIG channel archive (educational market) • Web Services for Remote Portals (WSRP) • As always, improved performance

30. Moving Forward…“Version 2” • Single Sign-On • JMS • Expanded development API • Environment controlled content rather and application controlled • Full support of SCT Banner solution • Macromedia “Blackstone” or CF version 7.0 • Expanded Channel architecture support

31. Expectations with “Version 2” • Will be based on Macromedia MX 7.0 platform. • Will be “object” based • Better support for external applications (i.e. Banner, Blackboard, T2, etc.) not based on CFML. • Better support of industry standards • Fall 2005 “beta” release • Possible package and licensing for marketing

32. So… how does it work? Live Demo… Keep our fingers crossed!