May 30, 2002 Minutes

Attending: Ed Anapol, Mike Baptiste, Pakis Bessias, Angel Dronsfield, Ken Hirsh (for Dick Danner), Ed Gomes, Nevin Fouts, Tracy Futhey, Ed Gomes, Peter Harrell (for Patrick Halpin), Billy Herndon, David Jamieson-Drake, Molly Tamarkin (for Ken Knoerr), Forrest Smith (for Melissa Mills), Kyle Johnson (for Caroline Nisbet), George Oberlander, Lynne O'Brien Mike Pickett, Rafael Rodriguez, Mike Russell, Fred Westbrook, Robert Wolpert, Stephen Woody

Guests: Ginny Cake, Rob Little, John Diaz, Randy Haskins, Rob Carter, Heather Flanagan, Chris Meyer, Jen Vizas

Call to Order: Meeting called to order 4:05 PM

I. Review of Minutes and Announcements:

• Video Services Subcommittee Update - Fred Westbrook: The subcommittee has posted a website that includes the charter, project timelines, membership, minutes, white papers, etc. http://www.duke.edu/web/video/ITACvideo/research.html
   
• Notes Migration Update - Rafael Rodriguez: Moving the Notes mail server from NT to Unix cluster. Currently conducting performance tuning on the servers. Have also implemented mail scanning for viruses. - Fred Westbrook commented that the server seems to be slow and asked if it will improve overtime. Rafael responded that the speed has improved and will continue to improve as the servers are tuned.
   
• Video Tele-conferencing Services Update- Mike Pickett: OIT has officially consolidated the staffing for the Tele-Video classroom. Educational Media Services will now be handling the scheduling, maintenance, and upkeep of the facilities. The room will stay intact and users will still call the same phone number for services.
   
• SAP HR/Payroll Update - Billy Herndon: The go live date for HR Payroll is 8/2. Communication to the users will come from HR Payroll. They are confident that they are ready for the transition. The training program is set and ready to be launched.
   
• Archibus Update - Mike Pickett: This software is used around the campus and medical center to track people and activities. In the process of trying to get a handle on who is using the software and the types of licenses they have. There is strength in numbers and we may be able to get better pricing. If you know of anyone who is using the application send email to Mike Pickett.
   
• MCNC Update - Tracy Futhey: Currently going through structural changes which may change the services. Over the next few weeks/months we will be getting in touch with faculty using the super computer center and get an assessment of the service Duke is receiving. If you know of people who use words like MCNC, Cray, Super Computer, etc. send email to Tracy Futhey.
   
• Computer Store Web site - Ginny Cake: The Blue Devil Delivery packet has gone out which includes information on the Duke Technology Advantage Program. The Web site has been updated with the new pricing.

ITAC Annual Report to ECAC

Duke Card Update, Past, Present & Future

• Online Access -Phone & Cable Bill Payments
• Parking Fines & Permits
• FLEX Deposits & Statements
• Off-line Interior Door Locks - Low cost solution where alarm monitoring and real-time updates not necessary, Available Fall 2002
• Network Print Management - Pilot Summer 2002 with OIT, Libraries, Office Products
• Inexpensive,
• $1 versus $3 for 1K microprocessor chip (greater memory = more $$$)
• Reliable
• Students swipe 10 times per day, less than 1% failure rate per year on
  magnetic stripe
• Standard
• Nearly every system with a magnetic stripe reader can interpret card
  number
• Fast - no delay while waiting for card to initialize
• Biometrics Information
• Student Records
• Connectivity Issues
• Feasibility and cost
• Security Concerns - counterfeiting, user authentication, confidentiality

• John Diaz

  in 1985 The card was a Polaroid photo in a laminated pouch which was hand encoded. The system consisted of 40 card readers the applications were very limited and included food service, retail stores and the library.

  The DukeCard in 2002 has become mainstream - faculty, students, and staff use it not only for access but for purchases. The Duke Card has a digital image with thermal printing. The system consists of 1,050 card readers and serves the enterprise. The applications include vending, laundry, copiers, door access, parking, athletic events, time & attendance.

  The Duke Card is currently in use at the Duke Marine Lab (food service, photocopiers, vending, laundry, retail and access will be coming soon); Durham Regional (food service, door access and parking, time & attendance); Raleigh Community (door access and time & attendance).

  Current & Future Initiatives include:

  off to a meeting astThe functional card technology has remained essentially the same since 1985: Magnetic Stripe + Bar Code. But a lot has happened in card technology over the past 18 years. Why do we still use the magnetic stripe?

  Is it Time for a Change? Possibly provide advanced storage such as:

  David Jamieson-Drake asked how long John though it would be before card readers came standard on systems.
  John answered that for the past several years it has been rumored that IBM and Dell will implement card readers but that hasn't happened. John also commented that external readers can be purchased for only $30-35

  Tracy Futhey commented the Sun Ray has some interesting possible applications in areas such as labs, and the medical center.

  Mike Baptiste commented that Engineering is looking at off-line locks for the new building. It will cost around a quarter of a million dollars to outfit the building. They have also been looking at the Proximity card.

  John Diaz mentioned that he has been talking with Dave Kirby in the Medical Center about securing workstations with a proximity card.

  Angel Dronsfield mentioned that OIT has a gateway in place to deposit money and process on-line invoices. If the Card Office is interested in utilizing any of these John could talk with Chris.

  Robert Wolpert commented that the Card Office is the only group on campus with photos of everyone on campus and asked if that really made sense. John responded that he is working with Suzanne Maupin on having the photos linked to the Enterprise Directory.

Content Management Functional Requirements

1. Enable non-technical staff to update and maintain their Web content more easily and efficiently using a variety of computing platforms and web development tools.
2. Provide a consistent web site management environment that will handle content creation, style, visitor usability, policy, workflow, versioning, and revision control for decentralized web infrastructures and content authors.
3. Facilitate the syndication (sharing and reuse) of web content, with the appropriate editorial accountability, by offering central facilities to index and cache content that originates anywhere on the Duke subnet.
4. Reduce inaccurate, outdated, redundant, or unauthorized content through automated content management processes, versioning, and workflow.
5. Make it easier for all Duke web efforts to achieve and maintain compliance with evolving standards (ADA and W3 compliance, University and departmental privacy policies, etc.) and provide the tools (repositories of approved templates, images, and logos, etc.) needed to support efforts to balance creativity and flexibility with brand consistency at the departmental, school, and University levels.
6. Make it easier for all Duke web efforts to support the full range of web content sources (development tools, database's, etc.) and web display devices (graphical browsers, text-only browsers, kiosks, and emerging small-screen platforms such as cell phones and PDA's).
7. Give first priority to the immediate needs of early adopters and second priority to anticipated future needs of an emerging CMS community.

• Massive growth of digital content
• some created specifically with web publishing in mind; some being made accessible via web gateways
• Increasing awareness that some, if not all of this digital content constitutes essential assets for the Duke community and , therefore, are worth managing and preserving systematically
• Past eighteen months of discussion and independent efforts, such as the "State of the Web" initiative, the digital library @ Duke, and experiences of schools and departments such as Fuqua have highlighted the opportunities that CMS support has for the Duke community
• Challenging experiences following 9/11 by a number of web-oriented organizations on campus to compile, leverage, and present existing digital content in new and important ways suggested the need for focused attention to new mechanisms for managing digital content.
• Formed as ITAC subcommittee in April to review and recommend
• Met regularly, especially in the last few weeks as activities have accelerated
• Status report presented at least once to ITAC
• Produced several key documents, created project website http://www.oit.duke.edu/CMSsub/
• Purpose of this briefing is to draw attention to two documents, brief you on a third document, and seek advice now and in the coming several critical weeks of our work
• Scope essentially serves as an outcomes statement for a sequence of efforts, beginning with what the subcommittee is doing now
• Scope document essentially describes an asset management environment
• Points to early adopters idea instead of "enterprise system" idea - critical distinction
• May to September time frame, culminating in the ground laying for a pilot
• This meeting represents near end of Phase 1
• Issue of the context of decision making and how to work now so that we can move ahead after September
• 4/16 Define CMS Lexicon - Concepts: Portal vs. channel, Glossary, working support web site.
• 5/16 Define Scope - What it is and isn't, Charter, Timelines, Goals, Milestones, and assumed needs.
• 5/24 Functionality Requirements - Outreach to stakeholder groups, Define and identify existing web processes, business models and best practices. Develop requirements.
• 6/10 Technical Requirements - Interoperability, infrastructure, XML, firewall, database, hosting, servers, logic design. Specs.
• 6/15 Stakeholder Feedback & Benchmarking - Refine needs and create opportunity for constructive debate. Refine requirements.
• July Narrow System Selection - Open forums (web community), Webinares, Vendor RFI/RFP (request for information). Vendor scorecards. Narrow vendors to 2 or 3 viable only.
• July Tactical Needs Assessment - Formal assessment for implementation of pilot. Staffing, cost, training. Develop implementation timeline.
• August Recommendations - Formal vendor discussions, including partners, consulting, and long term vision. Formal presentation of findings.
• September Pilot Planning - Selected early adopter groups. Refine specifications, prototypes, and prepare for pilot. Develop success measurements. (Library, News and Communications, Fuqua, Engineering)
• Self selected group, representing high potential for success, some resources to bringing to the table, a bit of technological expertise, and identified need for what a CMS can provide if done well
• Good mix of agencies with different needs
• Collaborative environment with division of labor: an opportunity to work out the policy, administration, procedural issues while minimizing risk and sharing technical support
• Pilot provides for an early win that is scalable organically as concepts are proved. Not a throwaway prototype; success expected as a criterion for moving forward.
• Gartner & Jupiter Research Group CMS Vendor Selection Criteria
• Tied to scope of work
• Revised to accommodate Duke's context
• Functionality (30%):
  • Content authoring,
  • Presentation,
  • Syndication,
  • Workflow,
  • Versioning,
  • Access services,
  • Delivery services,
  • Site management
• Tech-Architect (15%):
  • Platforms,
  • Scalability,
  • Usability,
  • Manageability,
  • Security,
  • Replication,
  • Application dev,
• Integration Cost (10%):
  • Initial costs,
  • On-going costs
• Services (15%):
  • Professional,
  • Support
• Viability (20%):
  • Financial,
  • Organization,
  • Market
• Vision (10%):
  • Financial,
  • Organization,
  • Market

• Paul Conway

  Background

  Status report

  CMS Scope Question: What are the goals, or what do we hope to accomplish with a Duke CMS implementation?

  Timeline

  Phase 1

  Phase 2

  Phase 3

  Pilot Goals

  Functional Requirements

  CMS Selection Criteria

  David Jamieson-Drake asked what they envision for approval criteria with work flow?
  Rob Little commented that it would drill down to the departmental/local level.

  George Oberlander commented that he has a concern, this is an ambitious project and they should consider including a wide variety of departments. It looks like the early adopters group is made up of aggressive, technically able departments. Should you not consider including departments who may not be as technically able? Yes the pilot will be successful but what happens when the smaller less capable departments try to use the content management system?

  Nevin Fouts added that the work that has been completed thus far is fantastic - it is a very complex topic. They have done a great job crystallizing the scope.

  Tracy Futhey thanked the group for their hard work and efforts. She commented that they might consider keeping things at a high level - worry that some of the words used are generalized and subjective. One persons common tools are not necessarily another's common tools. As the project moves forward need to have details - the system should support xyz.

  Mike Baptiste mentioned that the group is now moving out of high level and looking at the detailed standards. The team talked about how to open up the tech aspects to a wider group.

  Paul Conway commented that at this time they were avoiding prescriptive behaviors, the early adopters would work through the principles and they would emerge through the implementation.

OIT Systems Administration Summer Projects Update

• Over 70 projects starting or underway
• Many internal, "behind the scenes" changes
• Many involve participation in other groups' projects
• Some of particular interest to a wide user community
• Spam Protection Changes
  • SpamAssassin
  • RBL Milter
  • User-driven Sieve support
• Additional Security Measures
  • Continuing IMAPS/POPS migration
  • SMTP Auth corrections

• Rob Carter & Heather Flanagan

  Overview

  Email systems

File and Web Services

• Campus-ftp Server Expansion
  • Replacement (w/ATS) of DukeNet Tools CD A
• FS Server Reorganization
  • AFS code upgrades (to OpenAFS sever)
  • Re-architected redundancy model for better availability and performance
  • Wider distribution of new OpenAFS client
• Webmail Enhancements
  • Streamlined authentication for faster operation
  • Additional servers in webmail farm as needed (2 now)
  • New SilkyMail version
• www.duke.edu Enhancements
  • Newer, faster hardware
  • New site hosting hardware, vanity URLs
• Web-based Account Management Interface
  • Passwords,Mail forwarding,Vacation
  • etc.

Campus Lab Upgrades

• MacOS X integration efforts (w/ATS)
  • Shooting to develop solid OS X image for fall
  • Better Kerberos and LDAP integration in Mac labs
  • OS 9 option remains available if OS X fails to gel
• Windows Labs (w/ATS)
  • Win2K image for the Fall
  • new software versions, etc.
  • Redesign of authentication to provide AFS/IMAP SSO
  • New AFS client code for the labs
• Solaris Labs
  • New versions of standard open software packages
  • Standardization of software installation model
• Linux Labs
  • Tracking DULUG software enhancements
  • New lab Kickstart server to mirror DULUG image and possibly add lab
  • specific extensions

Ongoing External Projects

• System Support for Enterprise Directory Project
  • with Directory Services and Operations
• WebISO, Shibboleth, and WebAuth extensions
  • with Internet2, App Services, and Arts & Sciences
• Mass Storage Project
  • with Operations, BIAC, Provost
• News Services web development integration
• Content Management

No other Business

Robert Wolpert's 2001-2002 Report to ECAC