[LTER-mcm-pi] LTER Data Center views

Tue Jul 28 13:59:31 MDT 2015

Hi Folks,

I first heard about the data center idea on a NISAC call late spring.  
At the time, there were only a few IMs involved and I believe they 
received an EAGER to investigate the idea.  My first impression was this 
is an interesting idea, but I was not very excited by it because from 
what I heard I did not feel like this model was conceieved to serve 
science, rather it seemed it was aimed to simply maintain IM and take 
advantage of an opening.  However, I figured this is just in the 
planning stage and maybe it would grow into something, maybe even become 
visionary.  The docs that Peter Groffman sent around show that ideas 
have grown and some of the ideas seem useful, but I am still concerned 
that this model would not be science driven.  For example the GC would 
only have 2 science PIs on it.  Furthermore, I was seriously concerned 
that much of the proposed work would be to maintain really outdated, 
clumsy infrastructure.  In general, I see little vision here.  I would 
like to see something that specifically addresses weaknesses in the 
tools we have available to us and paint a picture of what could be 
improved, what specific services would be provided etc.  I worry about 
this because I thought the data center would go out for competition, and 
maybe I am wrong about this, but it seems like NSF is quickly moving 
towards this model.  If these folks are going to be given this 
opportunity, I think they need to tell us specifically what they will do 
and support.  A strength of their proposal is to support network IMs to 
develop tools, but with no specifics and no direction given, 
prioritization and effectiveness is a concern.  Finally, I think we 
would get a better conceived data center if this went out for 
competitive RFP.  Ultimately, the award may be to the same folks, but 
the current model they propose is heavy on corporate structure, but 
light on ideas of how to serve science.

Tina
> Michael Gooseff <mailto:michael.gooseff at colorado.edu>
> July 28, 2015 2:42 AM
> Thanks for these thoughts and perspective, Inigo.  Certainly this is a 
> bit more of an insider's view than the rest of us have.
>
> While I still am not crystal clear on the details of the proposed 
> vision, one aspect that seems to underlie this effort is a common IM 
> or db architecture for all sites (correct me if I'm wrong).  That's 
> potentially a significant challenge to any site that does not already 
> have an architecture that is similar to one that is being proposed (or 
> would emerge) as the overhead costs required to shift to a different 
> system would be steep and have to come out of the site grants (I 
> presume, unless funding was provided by NSF for a one-time effort to 
> get all sites on a common track).  On the 'user' end, if the way data 
> was provided changed signicantly (i.e., formatting or grouping), then 
> there's a potential set of challenges to users within and beyond the 
> network that rely on data.
>
> Perhaps I'm mis-understanding and the goal is not to change all site 
> IM architectures but provide an efficient core services system that 
> has a master db for all sites and much of the technichal detail about 
> that master system are the subject of debate within the IM group.  If 
> that's the case, then the challenge comes back to site IM support 
> having to interface/support both their site systems and the main core 
> system.  That is, having to work with potentially different db 
> formats, etc.  That still represents a bit of inefficiency that is 
> likely paid by most site grants, and probably also represents the 
> current approach.
>
> I think that the evolution of 25+ site IM approaches over 20+ years 
> puts us in a challenging space if the goal is to have common 
> architectures across all sites, and as a network we will have to 
> balance the investments in IM efficiencies with site needs and contexts.
>
> cheers
> -Mike
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Michael Gooseff, Associate Professor
> Institute of Arctic and Alpine Research
> Civil, Architectural, and Environmental Engineering
> University of Colorado
> Boulder, CO 80309-0450
>
> email: michael.gooseff at colorado.edu <mailto:michael.gooseff at colorado.edu>
> web: http://goosefflab.weebly.com <http://goosefflab.weebly.com/>
> phone: 303.735.5333
>
>
>
>
>
> _______________________________________________
> Long Term Ecological Research Network
> mcm-pi mailing list
> mcm-pi at lternet.edu
> Inigo San Gil <mailto:isangil at lternet.edu>
> July 27, 2015 10:05 AM
>
>
> Hi all,
>
> I am quite involved in the Information Manager ( IM ) led proposal for 
> a LTER Data Center; I started paying complete attention as soon as I 
> heard Saran Twombly was considering plans by the LTER IMs on the next 
> LNO Data Center (in lieu of a formal RFP).  Since Mike invited me to 
> chime in ( thanks! )  I am taking the opportunity to weight in on the 
> IM led developments and also express some alternate ideas here.
>
> In summary - The IM plans presented to Mike and the EB here, and the 
> ideas behind these plans reflect continuity.   While continuity may 
> sound great for LTER, in my opinion it is also a missed opportunity to 
> make the LTER Data Center work efficiently for the science and the 
> LTER scientist.  I back this by 10 years of experience working closely 
> with the LNO - I think the next Data Center can do a better job.
>
> I have been pushing for a total revamp on how the Data Center and IM 
> group operates, but I am unsure whether I will succeed with my push - 
> not too optimistic.  As the plans are, I am missing some critical 
> components.
>
> In essence, I would be bold about how the Data Center should operate, 
> and less concerned about maintaining the current status quo.  Some IMs 
> on the LTER IM group feel like I do, but others may disagree.
>
> I would enforce coordination where coordination can be attained: Even 
> though all LTERs are different, there are some common IT aspects to 
> all LTERs. It would no longer be an option to have 26 architectures 
> (to be maintained) to do the same core functions, in my view, we would 
> have one common core for all LTERs and then each LTER would maintain 
> their custom needs.
>
> The effort saved using a common core infrastructure will be used to 
> serve LTER science needs -- we would place talent to work with teams 
> that do interesting science, perhaps favoring those cross-site and 
> synthesis projects, but taking into account any LTER projects.
>
> I also propose a bit different organizational - I would greatly 
> simplify the diagrams shown in the materials that Mike enclosed.  I 
> would go for a more traditional NSF structure; with a lead PI and a 
> team of other specialized talented individuals tasked with 
> accomplishing a set of goals that are proposed by the LTER community 
> (that is, you) and prioritized by the LTER community.  I would also 
> formally change how LTER IM teams operate - IMs would contribute to 
> common infrastructure development and upkeep in their areas of 
> expertise - this would be required.
>
> Operational tweaks: I am a believer in transparency and openness. We 
> all work better when there is mutual trust, and one way to nurture 
> trust is to be as transparent and open as possible.  Simple changes - 
> I would record all meetings, would open those for participation. Also, 
> we would have an open community process to proposing Data Center 
> tasks, void of tech-jargon.   Also revising the Data center priorities 
> should be community weighted (think the We the people White house 
> initiative), and with the oversight of the NSF (under cooperative 
> agreement).  However, the Data Center group will have the complete 
> independence on how to accomplish the goals concerted by the 
> community.  This also contrast with the proposed model, which operates 
> more like it does now ( an even more IM-heavy NISAC like group ).
>
> Technologically speaking I am proposing re-use of open source products 
> backed by a strong community.  I would have a team that re-uses and 
> customizes the best synergistic modern products.  Contrast this with 
> the proposed ideas: revive custom in-house solutions which in my view 
> are too expensive on the short and long term and may not have served 
> LTER science needs as expected. I would revise the PASTA effort -- see 
> how much is being used as it is. I would re-visit the PASTA components 
> of the current implementation that do not serve the purpose of solving 
> actual LTER science needs, and divest time and efforts into practical 
> scientific projects.
>
> This is a summary, I have more detailed plans, but I wanted to 
> emphasize my differences with what you see in the PDF and PPT docs. I 
> am tempted on presenting these ideas on an alternative proposal, but I 
> am still hopeful that all IMs can agree in one common plan. I have 
> been successful in stopping some aspects of the proposed IM plans that 
> did not make sense to me, like having an independent financial 
> institution manage the grant, etc. In any case, these will all unfold 
> by the time the ASM comes ( a month? ), Saran would like to resolve 
> ASAP, as whatever the next Data Center is, will have to roll out ops 
> by Spring next year.
>
> I am all ears about what you think the Data Center should be.  I know 
> Diane's group was successful in splitting the communications from data 
> center ops, and I am sure Diane's group have some specific results in 
> mind. If you want to devote some time in a phone conversation or 
> email, all the better -- the Data Center should work for you, and you 
> have a voice.
>
> Depending on the outcome of the Data Center, I may want to present a 
> plan for my involvement involved with MCM-V in terms that preserve 
> what you want to do and the cost that you are looking for (~$50k).  
> This should come around September or October.
>
> cheers,
> Inigo
>
>
>
> On 7/26/15 10:10 PM, Michael Gooseff wrote:
>
>
> -- 
>
> Inigo San Gil
> +1 505 277 2625
> http://scholar.google.com/citations?user=foIppL4AAAAJ&hl=en
> _______________________________________________
> Long Term Ecological Research Network
> mcm-pi mailing list
> mcm-pi at lternet.edu
> Michael Gooseff <mailto:michael.gooseff at colorado.edu>
> July 26, 2015 10:10 PM
> Hi all,
>
> Please see the info below (and attached) in regards to a new approach 
> to a Network Data Center approach that is coming from the Network IM 
> community.  Everyone is seeking a state of Kumbaya, but no one is 
> quite sure the attached plans will achieve it.
>
> (My email address replaced Diane's on several network lists, but not 
> this one.  My apologies for the late delivery of info.)
>
> _Please let me know what you think about this plan_.  Peter is largely 
> asking for the lead PIs to convey the thoughts and reactions from 
> their sites and I have a teleconf set up with him for Thursday of this 
> coming week to discuss. /If you could get me any thoughts before 
> Thursday, I would appreciate it/.
>
> Inigo - this includes you, of course!
>
> Best,
> Mike
>
> P.S. - Bonus points to the first person who understands the reference 
> to Kumbaya in the message above!
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Michael Gooseff, Associate Professor
> Institute of Arctic and Alpine Research
> Civil, Architectural, and Environmental Engineering
> University of Colorado
> Boulder, CO 80309-0450
>
> email: michael.gooseff at colorado.edu <mailto:michael.gooseff at colorado.edu>
> web: http://goosefflab.weebly.com <http://goosefflab.weebly.com/>
> phone: 303.735.5333
>
>
>
>
> _______________________________________________
> Long Term Ecological Research Network
> mcm-pi mailing list
> mcm-pi at lternet.edu

-- 

Cristina Takacs-Vesbach

Associate Professor
Department of Biology
University of New Mexico
MSC03 2020
Albuquerque, NM 87131

Phone:505-277-3418
Fax:505-277-0304

website:http://pearl3.unm.edu/site/main.html

Fedex and DHL Shipping Address:
University of New Mexico
Castetter Hall Room 133
Albuquerque, NM 87131

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lternet.edu/pipermail/mcm-pi/attachments/20150728/b11fa437/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.lternet.edu/pipermail/mcm-pi/attachments/20150728/b11fa437/attachment-0001.jpg>