Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Shared Services - Program Document Sec 3.1 - Preliminary Overview

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Program Document Sec 3.1 - Shared Services - Preliminary Overview

This is a draft iteration of section 3.1 of the Program Document outline. The purpose is to give a provisional sense of the Program Staff's evolving idea of how the Shared Services area of work might be framed, to help the Shared Services Working Group orient its contributions to the first full draft of the "Program Document" (see note below); and to contextualize milestones proposed for the Workshop 3 to Workshop 4 period. It is fully expected that the ideas sketched in this draft will be shaped, reshaped, and refined by Working Group and other contributions during the weeks between W3 and W4.

Note: "Program Document" is a term that Bamboo Program Staff are currently using to name a document that describes Bamboo's long-term arc -- the "7-10 year" vision called out by David Greenbaum and others at Workshop Three. A subset of the work described in the Program Document will be included in a Bamboo implementation proposal to the Mellon Foundation in Fall 2009.

3.1: Shared Technology Services for the Arts, Humanities, and Interpretive Social Sciences

Shared Technology Services for the Arts, Humanities, and Interpretive Social Sciences are envisioned in three mutually-influencing stages: a services "marketplace"; a set of "common services" whose quality is refined by the Bamboo community; and a "cloud" (or ubiquitous) deployment of shared common services.

In the "marketplace," anything goes: tools and services are built by anyone, to address any broad or narrow need. "Common services" are those that have been standardized in ways that enable IT organizations to run them more easily and reliably for their own university (or other institution). When services are moved to a "cloud" they can be easily and reliably consumed across institutional and other boundaries: cloud services a scholar uses do not need to be provided by her own university, but may be provided by a number of universities, institutions, vendors, or consortia -- yet work in concert to enable her work.

The graphic illustration of these three evolutionary stages is further explained in the text below.

The "'cloud' deployment" stage of evolution (in shades of gray in the diagram, below) is likely to emerge after the first three-years phase of Bamboo Implementation (Phase I) -- current thinking is that research, proposals, and possible proofs-of-concept related to ubiquitous deployment are likely to evolve during the Phase I period.




3.1.1 A Marketplace of Services

Services applicable to scholarship have been and continue to be developed for scholars, projects, disciplines, institutions, etc. Such projects may make information about themselves discoverable by a tool or framework that evolves to support the Bamboo Marketplace, or may take active steps to register information in the marketplace. Marketplace mechanisms for discovery of available services will help scholars identify whether their need is already addressed before they put out a "bid" to technologists who might be interested in filling a gap; these mechanisms will also help technologists identify services that they might compose into new, enhanced service offerings. Mechanisms in the same framework will track usage of developed services, and provide for feedback collection; these will be presented in ways that are meaningful both to scholars and to technologists. Ideally, adherence to development guidelines and standards for data/content interoperability will be encouraged by incentives to build services more likely to become Bamboo "Common Services." There may be minimum constraints for participation in the services marketplace, such as open source software licensing. Another key question will be whether and how any notion of "membership" in a Bamboo, higher education, or other community comes into play.


3.1.2 Common Services: Definition and Reference Implementation

Candidates for definition, implementation, and refinement as Common Services will come from within the Bamboo consortium, building on scholarly practice narratives, activity definition, and "Services Roadmap" work begun during the Bamboo Planning Phase; from disciplinary communities in the digital humanities (e.g., existing tools and services projects who are motivated to offer their technology in ways compatible with or part of Bamboo "Common Services"); and also from the "Marketplace of Services" (cf. 3.1.1, above). The way Common Services are described and accessed will follow standard formats and protocols, agreed upon by the Bamboo Community. Similarly, Common Services will have a minimal set of standard characteristics, which might include integration of standard utility components or services (e.g., storage, authentication); integration of mechanisms that permit a deployed service's quality metrics to be measured; and compliance with versioning standards (for evolution and backward-compatibility). Formal release (publication) of a Common Service will include at least one reference implementation -- a working version of the service -- deployed in a proof-of-concept environment (i.e., not guaranteed to be always-available, and only to be used in experimental contexts). Members of the Bamboo Consortium will be the primary 'actors' in this stage of evolution: identifying appropriate standards, choosing candidate services (based on community and "marketplace" interest/value); defining & standardizing them; building and/or refining reference implementations; and determining whether, when, and how a service ought to evolve.

3.1.3 Common Services: Local Deployments

Common Services may be run (and/or reimplemented and run) in local or regional deployments. The deploying institution or group of institutions would be wholly responsible for availability and maintenance within the local or regional context. It is expected (but not required) that usage of these local or regional deployments would be restricted to the deploying institution, group, etc. Bamboo as a consortium would make no guarantee regarding these deployments, and would expect potential service consumers to be notified of this as part of a full, standards-compliant description of the offering. This and analogous expectations might well be expressed as elements of the license under which Common Services are released. As experience with local deployment deepens, evolution of a favored, standard, and stable deployment environment might give rise to valuable activity in prototyping and packaging a Bamboo Common Services "appliance" -- i.e., a set of deployment technologies and configuration procedures/scripts, combined with a set of Common Services to be deployed on those technologies, that can be set up with minimal overhead at colleges, universities, libraries, museums, and similar institutions. Such an "appliance" may be an interim stage between local deployments described in this section of the Program Document, and the "cloud" vision described in 3.1.4, below.

3.1.4 Sharing Common Services: Cloud / Ubiquitous Deployment

The "'cloud' deployment" stage of evolution (in shades of gray in topmost diagram, above) is likely to emerge after the first three-years phase of Bamboo Implementation (Phase I) -- current thinking is that research, proposals, and possible proofs-of-concept related to ubiquitous deployment are likely to evolve during the Phase I period.

At this stage of evolution, services are deployed on redundant infrastructure and made available across institutional, regional, and/or disciplinary boundaries: a scholar does not need to use her institution's deployment of a given service, but may use one that is broadly available. One way of thinking of such an arrangement is analogous to "cloud computing." [1] Characteristics of this infrastructure would enable redundant deployments to be accessible to end-users via fail-over mechanisms that would guarantee availability (if one instance of a service fails, another instance will fulfill a scholar's request). Redundant deployments might be provided by for-profit or non-profit vendors, institutions, regional or disciplinary organizations, governments, etc.; the Bamboo consortium's formal relationship with these providers is an open question. Business models and mechanisms (to be defined) would address the costs of service provision.

[1] In 2009, an example of what is meant by "cloud computing" might be the Amazon S3 (storage) service and/or Amazon EC2 "elastic compute cloud," both provided by Amazon Web Services, LLC, and available to anyone via distributed server farms in the U.S. and Europe; the actual locations of those server farms are more-or-less immaterial to service consumers (stored data and access to compute resources are available from anywhere). In the commercial model, these distributed server farms are linked by the fact of ownership by Amazon Web Services, LLC. For a Bamboo "cloud," a different model would need to be developed: linkage between distributed provisioners of services might be consortial or contractual, for example, rather than via ownership or subsidiary relationships. The complexity of such a business model is one reason that this stage of evolution is forecast for Bamboo's longer-term future.

  • No labels

3 Comments

  1. Unknown User (mspalti@gmail.com)

    A few comments on the program document, section 3.1.1. 

    I wonder about the phrase  "marketplace of services".   At first blush, it worked for me.  But considering our broad audience, would the associations of the metaphor be attractive to everyone?  Also, the term "marketplace" suggests -- to me at least -- kinds of transactions that are not inclusive of all that we're talking about here.  I don't have great suggestions for another term, but staying close to the marketplace idea, I wonder about a "Bamboo services exchange," "community exchange", "exchange mechanism", etc.  This seems to allow for the concept of a "bid" without marginalizing the exchange of gifts.  Just a thought.

    "track usage of developed services, and provide for feedback collection; these will be presented in ways that are meaningful both to scholars and to technologists"  I'd push this just a little --  toward identifying and gathering the kinds of usage data and feedback that are useful to both scholars and technologists.  It seems like what we don't want to imply is: "collect the usual stuff and then find ways to present it in a format meaningful to scholars."  Scholarly interests influence the data collection as well.

    "Ideally, adherence to development guidelines and standards for data/content interoperability will be encouraged by incentives to build services more likely to become Bamboo "Common Services." -- I agree with this and wonder if it could be developed a bit more.  Provisionally, is it possible to say something about what the incentives are (money, support, collaboration, recognition) and who provides them (Bamboo, external funding agencies, leaders in the Bamboo consortium)?

  2. Unknown User (jim.muehlenberg@doit.wisc.edu)

    I have a few reactions or suggestions to offer to various parts of Steve Masover's excellent draft here.

    [Program Document Sec 3.1 - Shared Services - Preliminary Overview]  "... to help the Shared Services Working Group orient its contributions to the first full draft of the "Program Document"

    Comment:  I'm still not clear on expectations for working group contributions, aside from reacting to this draft. Is there other content we're to be helping draft? Or.....?

    [3.1: Shared Technology Services for the Arts, Humanities, and Interpretive Social Sciences]  "In the "marketplace," anything goes: tools and services are built by anyone, to address any broad or narrow need."

    Comment:  Is the Marketplace another way of thinking of the Exploration Labs that have been outlined?

    [First Diagram - the triangle of ovals]

    Comment:  It was useful of Steve Masover to remind us that Common Services was the original goal, and the Cloud was more recent, and the Marketplace is the newest introduction. Also, I'd argue that Sustainability is another strong attribute of Common Services (see the Changing Technologies and Unsustainable Tools theme for why this is so important).


    [3.1.1 A Marketplace of Services]  "Such projects may make information about themselves discoverable by a tool or framework that evolves to support the Bamboo Marketplace."

    Comment:  Somehow this view of the Marketplace seems more concrete and organized in this language, a "framework," compared to the earlier "anything goes" reference. Is in fact the Marketplace Bamboo centric or truly what goes on in the wild?

    [3.1.2 Common Services: Definition and Reference Implementation]  "Formal release (publication) of a Common Service will include at least one reference implementation -- a working version of the service -- deployed in a proof-of-concept environment (i.e., not guaranteed to be always-available, and only to be used in experimental contexts)."

    Comment: As written, this seems to imply that a Common Service deliverable is more of a specification (like an OKI OSID) rather than a true production-quality service that the community can in fact depend upon. Steve Masover indicated that was not the intention, but the description here makes it sound this way to me.

    [3.1.2 Common Services: Definition and Reference Implementation]  "... building and/or refining reference implementations;"

    Comment: I think emphasis on adopting good services from the marketplace should be stressed, not only the build/refine language; we don't want to build everything within or for Bamboo, I assume.


    [Last two diagrams]

    Comment:  assume these should say "Bamboo Implementation Kickoff: January 2010" rather than 2009?

  3. Unknown User (mspalti@gmail.com)

    3.1.3 Local Deployments

    Folks, a quick comment, perhaps related to Jim's mention of the exploration labs. 

    Local deployments seem to map perfectly onto the "explore" area of activity in Chad's consortial model. In a regional context, I wonder if the exploration of various approaches (business models?) for shared services would eventually inform Bamboo planning for cloud-based shared services. 

    Since I was asking myself these kinds of questions as I read, it might help my understanding if the services program document made a just few illustrative connections between service development and the ongoing activities outlined in Chad's model (explore, plan, build). 

    I think this section does an impressive job of articulating the technical requirements and terms of service.