Category Archives: Uncategorized

The Anatomy of a Book- Part 1


Authors Note: This is part one in a multiple part series on the anatomy of the book. This part will talk about the basics of books including materials and formats, next one will identify parts of the book itself.

View of Beinecke Rare Book Library's Cube of Books. (Source Simon King, CC BY-NC-ND 2.0) View of Beinecke Rare Book Library’s Cube of Books. (Source Simon King Flickr, CC BY-NC-ND 2.0)

When I got to library school I may have loved books and reading but damned if I had no idea what made up a book. Worse for me, my first days on campus were started in a rare book library where I quickly learned through a crash course of book history. My lack of knowledge for the parts of the book became quickly clear to me, and so, as part of a two part post, I’d like to impart what I’ve learned about the anatomy of books to future and current (and, hey, former as…

View original post 1,122 more words


Two Important aspects to consider when designing or adopting an ILS

Introduction to ILS

“The Integrated Library Systems (ILSs) were developed in the 1990s primarily for printed material,” (Yang 1) yet, as is observable in many libraries, the means by which libraries automate many of their more mundane functions is changing; the struggle remains in keeping up with these changes. As is true of most advances in technology, ILS advances should be made with the framework in mind to simplify the users needs and to avoid unneeded/ unwarranted stress.

Each group of participants in the library systems has needs that must be addressed when thinking about an Integrated library system.  In this blog post I will be addressing the librarians who, when thinking about ILSs, must ask the question of “Does the product meet my needs?” I seek to address this question within the context of Electronic Resource Management (ERM).  The second group that I will be considering in this post is library users, who would pose the question more like this: “Can I find what it is I need?” For their needs, I will be looking at Discovery Tools. The purpose here is not to be thorough in addressing ILSs, but to provide some context by which we can better understand the systems we engage with as a profession.

There are many aspects to contemplate when considering designing or adopting an Integrated Library System: technology, services to your library, cost, open source or proprietary product, users, collaboration, dealing with vendors, and communication with other systems and organizations. As with any large scale/ high value purchase, the more known about the item before hand the better informed the choice will be, and the more confident the buyer will be that the correct decision was made.

From the Librarians Perspective: ERM

As librarians, we are generally more aware of the information and work that is required to make knowledge accessible, findable, and retrievable, but the ends and outs of an Integrated Library System are not usually something we think about every day. In her article From integrated library systems to library management services: time for change?  Sharon Yang makes the observation that “Ideally, a library system should be able to add, index, display, and search RDA fields, but not all the current [as of March 2013] ILSs are readily made for this task.” (Yang 1)  Yang goes on further to state that “at the center of the new library systems is a knowledge base which stores important information needed for a library’s daily operations.” (Yang 4) These new electronic resource management (ERM) systems seek to simplify the entire process. One way in which ERM systems help facilitate holistically integrated ILSs is by requiring “library staff to login to separate modules for tasks based on the division of work or library functions.” (Yang 3) This meaning that Librarians do not need to login to multiple portals or systems to fulfill their various functions and responsibilities, but can do everything within the same system at various points.

One of the larger debates taking place in the world of libraries at the moment is on whether to adopt Open Source Software (OSS) or to purchase a Proprietary Product (PP). There are distinct advantages and disadvantages to both, but the most important factor is your need and an understanding of what is being purchased (short and long turn). Sigi Goode noted that, with respect to not utilizing OSS,

“a lack of conventional and ongoing support [is] a critical factor in [library administrators’] decision not to adopt and [they] perceived a lack of reliable support avenues: ‘we think there’s a real lack of tangible support.’ Managers appeared concerned that, if no equivalent to commercial support existed, they would risk having to support their software applications with their own resources. One respondent wrote, ‘We’re not interested because it’s not a commercial offering.’ Tellingly, another wrote, ‘we really don’t know anything about them and don’t want to know. We want someone we can sue when things go to the wall.’” (Goode 675)

Andrew Asher et al. point out in their article Paths of Discovery: Comparing the Search Effectiveness of EBSCO Discovery Service, Summon, Google Scholar, and Conventional Library Resources that “one critical question for libraries considering the implementation of a discovery tool is whether the tool would add enough value to justify its cost in comparison to tools like [Google Scholar] or a library’s already implemented suite of research databases.” (Asher et al.  477) Another problematic situation arises when the company that the library has been doing business with for many years goes bankrupt or merges with another institution? Many adapt this question as to a reason for supporting OSSs in the library because all of the content is stored and managed by the library itself, and not by an outside vendor. Kris Ven et al. noted in their article Should You Adopt Open Source Software? that  “Organizations using proprietary standards… might face significant costs during data migration” (Ven et al. 56)

From the Users Perspective: Discovery Tools

For a great background, accompanied with vendor reported distinctive features and general user comments, I strongly recommend the reader to find the chapter entitled “Major Discovery Product Profiles” in Library Resource Discovery Products: Context, Library Perspectives, and Vendor Positions by Marshall Breeding.

The library has come a long way in making access to information easier for it’s users.  This is because, “within the library, faculty and students have come to expect a simplified, fast, all-inclusive, and principally online research experience that mirrors their use of Google and other search engines.” (Asher et al. 464) There are a myriad of problems here though, one of the greatest of which is the reliance on the Discovery Tools algorithm to do the research for the user.  Andrew Asher et al. emphasize this point strongly at various times in their article:

  1. “The situation of information overabundance makes strategies for evaluating and discerning high-quality information of paramount importance. Unfortunately, students often lacked the conceptual understanding required to complete this task adequately, instead relying on the search systems to do the work for them, in particular, by using the search engine’s relevancy rankings to determine resources’ relative quality.” (Asher et al. 472)
  2. “By following this practice, students are de facto outsourcing much of the evaluation process to the search algorithm itself.” (Asher et al. 474)
  3. “Given their uncertainty in evaluating resources, many students imbued the search tools themselves with a great deal of authority.” (Asher et al. 474)
  4. “Since what is found most quickly and most easily is also what is most likely to be used by students, each system’s biases in the types of resources is reflected in the resources they choose.” (Asher et al.  477)

For more on why this is not necessarily the best method for conducting research, see the section “FALLACY, LOGICAL: Fallacies of weak induction” in the New Dictionary of the History of Ideas. It is very likely that the results will get the user what they need, but that does not mean that the user should solely rely on the Discovery Tools algorithm to determine what it is that is needed for their research.  The Discovery Tools of today are continuing to be improved upon, and it is this authors hope that the need of relevancy ranking biases, and cross communication upon competitive vendors will be more fully addressed in the coming years.


    ILSs are changing rapidly, just as the way major advances in technology over the past few decades have dramatically changed the way things have been done. The key concepts in all of this though are 1.) Does it simplify my life (or the life of the users)? and 2.) How do I use these new tools?


Asher, A. D., Duke, L. M., & Wilson, S. (2013). Paths of discovery: Comparing the search effectiveness of EBSCO discovery service, summon, google scholar, and conventional library resources. College & Research Libraries, 74(5), 464-488.

Goode, S. (2005). Something for nothing: Management rejection of open source software in Australia’s top firms. Information & Management, 42(5), 669-681. doi:

Joseph, P., & Namjoo, C. (2013). A comparison between select open source and proprietary integrated library systems. Library Hi Tech, 31(3), 435. doi:

Major discovery product profiles (2014). Retrieved from

Stump, D. J. (2005). Fallacy, logical. In M. C. Horowitz (Ed.), New dictionary of the history of ideas (pp. 775-776). Detroit: Charles Scribner’s Sons. Retrieved from

Ven, K., Verelst, J., & Mannaert, H. (2008). Should you adopt open source software? IEEE Software, 25(3), 54-59. doi:

Wang, Z. (2009). Integrated library system (ILS) challenges and opportunities: A survey of U.S. academic libraries with migration projects. The Journal of Academic Librarianship, 35(3), 207-220. doi:

Yang, S. (2013). From integrated library systems to library management services: Time for change? Library Hi Tech News, 30(2), 1.

SDLC as a model for project management

What is SDLC and how can we use it when developing a strategy for project management? In this post, I hope to answer this question by examining the impact of SDLC on users’ and stakeholders’ involvement.


 Systems Design Life Cycle is a model, or a series of models, that seek to explain the process by which a product, or service, comes into being.  As Mahizharuvi et al. state in their paper A Security Approach in System Development Life Cycle  “Many models are being adopted by … companies, but most of them have similar patterns. Typically each phase produces deliverables required by the next phase in the life cycle .”(Mahizharuvi, 2011, p.254)

 The Waterfall Model is “the base for all models” of system development .”(Mahizharuvi, 2011, p.254), and as such it is a good place to examine the theories behind system development.  The waterfall model consists of five linear parts:

  1. Requirements (which leads to)
  2. Design (which leads to)
  3. Implementation (which leads to)
  4. Verification (which leads to)
  5. Maintenance

 In the requirements phase, a need has already been established and the developers look at everything that is needed to get that system actualized. In that sense, the requirements phase is like an NFL Coach who has a vision for his team to win the Super Bowl and looks at his team and staff to figure out what he has and what it will take to achieve his goal. After the coach determines what is needed to achieve the vision, he begins to design a program for his team to follow that will push them to achieve the desired outcome. The design process includes the practice schedule, the workout routines, to some degree the eating habits, and the psychophysiological and spiritual well being of the team.  One important component to the design process is bringing the team together to work as one; to bring them into the vision.  Implementation takes the entire design of the coach and actualizes it through practice and training. Verification comes when the team is competing in regular season games while maintenance comes into reviewing the game and analyzing the play for what needs improvement and fine tuning the design and implementation strategies.

Cohen et al. (2010, p. 21) highlight two SDLC models in their paper A Software System Development Life Cycle Model for Improved Stakeholders’ Communication and Collaboration: a traditional model and an IS acquisition process model. The “traditional phase” of SDLC includes the following aspects:

  1. Requirements (which leads to)
  2. Analysis (which leads to)
  3. Design (which leads to)
  4. Construction (which leads to)
  5. Testing (which leads to)
  6. Installation (which leads to)
  7. Operation (which leads to)
  8. Maintenance

 The IS acquisition process model(Cohen, 2010, p. 21) is very similar in construct, but, as you can see below, there are slight differences in strategy.  The IS acquisition process model looks like this:

  1. Justification (which leads to)
  2. Evaluation (which leads to)
  3. Preparations for Acquisition (which leads to)
  4. Request for Proposals (which leads to)
  5. Vendor Evaluations and Choosing (which leads to)
  6. Contract Negotiations (which leads to)
  7. Implementation and Maintenance

Before going further, I want to provide some context for how I am looking at Project Management (PM). PM is the process by which an objective is established, and a plan of action is created in order to actualize the desired result with clear directives on who will be doing what when and, to some extent, how.

 All projects are designed to be used by someone. In the library, our users are, generally, the public; when we are designing systems we must always keep our users in mind. The result of our work should be an easy to use product that is simple and intuitive.  Bhute et al. display various diagrams in their article System Analysis and Design for Multimedia Retrieval Systems that illustrate various relationships between Administrator/Manager and Users and how they interact with systems and servers.

 One aspect of the SDLC that we have been missing so far is…



 According to the Internet Theft Resource Center there have been a total of “521 security breaches” so far this year (2014) compromising approximately “17,829,689 individuals” (perhaps some of those are repetitive). (ITRC, 2014)  As is True in life, one of the most valuable assets we possess is trust, and in the world of databases that trust takes on the form of security of personal information such as name, email address, personal address, telephone numbers, social security numbers, et c.  As designers and administrators of databases, there is a moral duty to the consumer that their information cannot be breached.

 How do we fix this in our concept of the System Design Life Cycle and Project Management?

 Mahizharuvi et al suggest that security requirements be an inclusive component of and “identified during the system development lifecycle.” (Mahizharuvi, 2011, p.253) They go on further to state that “to define requirements, systems engineers may, in conjunction with users, perform  a top-down and bottom-up analysis of possible security failures that could cause risk to the organization as well as define requirements to address vulnerabilities.” (Mahizharuvi, 2011, p.254)

 Spears and Parrish “suggest that the time is ripe for IS professionals to begin incorporating security into the analysis and design of an IS as a means to reduce security vulnerabilities and data breaches.” (Spears, 2013, p.18)

 The biggest component of incorporation of security into the SDLC and PM spheres is to have them as a functional part of the beginning, middle, and end of the process as opposed to an ad hoc inclusion at the end.



  • Avinash N Bhute, B B Meshram. (20113). System analysis and design for multimedia retrieval systems  . The International Journal of Multimedia & its Applications, 5(6), 25-44.
  • Identity Theft Resource Center. (2014). 2014 ITRC breach report. Retrieved from
  • P.Mahizharuvi, a. D. K. A. (2011). A security approach in system development life cycle. International Journal of Computer Technology and Applications, 2(2), 253-257.
  • Shalom Cohen, Uzi De Haan, Dov Dori. (2010). A software system development life cycle model for improved stakeholders’ communication and collaboration  . International Journal of Computers, Communications & Control, V(1), 20-41.
  • Spears, J. L., & Parrish, J. L.,Jr. (2013). IS security requirements identification from conceptual models in systems analysis and design: The fun & fitness, inc. case. Journal of Information Systems Education, 24(1), 17-29. Retrieved from