I provided the following introduction at the recent Digital Systems and Stewardship (DSS) Town Hall meeting and thought I would redistribute it as a blog post.
Hello, my name is Ben Wallberg and I manage the Software Systems Development and Research department, or SSDR. The department has 5 software developers, 1 web developer, and 3 Graduate Assistant software developers devoted to supporting College Park specific services. We also have 2 systems analysts who support consortial services, with joint membership in the Consortial Library Application Support (CLAS) department.
The best way to understand what we do is to break down the department name into its four component words.
Software – SSDR operates and maintains many of the DSS server based applications.
We install and configure those applications, perform upgrades, and provide development support. Each application has an owner with whom we coordinate on changes and future directions for the application. For consortial applications like Aleph and Metalib, the owner is the CLAS department. For Digital Collections and DRUM it is the Digital Programs and Initiatives (DPI) department and for the Libraries’ Website it is the Web Advisory Committee. Note that Libi does not currently have an application owner, which we are working with Library Assembly to rectify.
Systems – Websites and other server based applications are generally not run in isolation but as collections of systems and services. You are familiar with the end user facing applications but to operate, these require an unseen infrastructure. Relational databases supporting multiple applications are an example of these backend systems. Fedora Commons is a metadata and asset management tool behind Digital Collections. Solr is a search platform used by DRUM, Digital Collections, and the new SCPA Scores database. This web of interconnected services extends also to external systems such as Wufoo hosted forms which are embedded into the Libraries’ Website or the Shibboleth distributed identity management systems used for login to consortial applications.
Development – Also referred to as programming or coding. We write some code from scratch but this is expensive work so we try to minimize the amount of original code we write by building our applications from existing applications, toolkits, and services and then using locally developed code to integrate them. The majority of time taken on any development project is not in the actual coding; it is the project planning, requirements gathering, issue tracking, version control, testing, and documentation.
Research – In this context research primarily means mean investigation into new software and systems. This could cover front- or back-end applications, cloud services, web service APIs, or development tools. Adoption of new software is often constrained by the desire to get the highest return on our investment which is based on factors such as how well we can support the underlying technology and how well can reuse the tool for multiple purposes. To learn how applications work we trial our own tools and applications as well as offer sandbox environments for Library staff to run applications they have an interest in evaluating.
Finally, these four functions: software, systems, development, and research are performed in the context of the Libraries’ strategic plans, needs of application owners, maintaining availability of critical systems, and multiple major and minor projects with overlapping timelines and dependencies.