EarthCube Architecture


NSF has funded three projects to develop conceptual designs for EarthCube (see This session will bring together team members from the three projects to present updates on the progress of their design work, followed by an open discussion with the community to explore similarities and differences in the approaches. The purpose of the session is to identify where the approaches are convergent, to understand the rationale for differences, and to provide a forum for community feedback on design development.  This will provide important input for the projects to refine their work, as well as an opportunity for community engagement in EarthCube conceptual design.


Title: EarthCube Architecture

Session Lead: Steve Richard (Arizona Geological Survey)


Speaker 1: Steve Richard

Presentation Title: EarthCube Architecture Forum Results


  • What is EarthCube?: a cyberinfrastructure that fosters new, transformational geoscience.  How? By enabling discovery, evaluation, and access.

  • What is Architecture?: A high level view of a system that can be used as a guide to assess if something fits or does not fit.

  • Architecture Needs To: provide framework, occupy middle ground between uncoordinated technology-bazaar model and the single monolithic system model, and describe the communications necessary and the objects that need to be exchanged.

  • Guidelines: architecture dictates interfaces instead of technology; architecture should be decoupled from the components, which are modular.


Speaker 2: Ilya Zaslavsky (UCSD)

Presentation Title: Geoscience Enterprise Architecture for Research (GEAR)


  • The Science Enterprise: ask, collect, hypothesize, test, and document, curate, and disseminate.  Also increasingly, integrate, analyzes, and collaborate.

  • Purpose and Scope of Conceptual Design:

    • Purposes: framework for different components to fall into place; a way to access gaps and priorities, and to bring different communities together on a common, easily understood platform.

    • Scope EarthCube: Defined through interactions with stakeholders.

  • The pitfall: a quote from Paul Brubaker, and in essence, avoid investing resources to design something that is unusable.

  • Inputs: white papers, domain workshop results, review of existing cyberinfrastructure, and surveys.

  • Technical Approach: federation of systems approach; define high-level components and communication channels; and emphasis on communication, system analytics as feedback mechanism driving evolutionary development.

  • Perspectives on EarthCube: open federation of systems, cross-domain information integration, efficient execution of research workflows, alignment of stakeholder interest, and scholarly communication.

  • Communication, Metrics: System management depends on knowing what is working.  Use information is used to provide feedback.

  • Content and Computation: Resource system, registry system, and data processing system.

  • Information model and Design report outline are also presented.

  • Concerns: top 5 are presented - hitting the right level of granularity, identifying necessary communication channels, balancing current and future requirements, constructing a self-organizing plug-and-play system, and inventorying and characterizing existing components.


Speaker 3: Phil Yang (NSF Spatiotemporal Innovation Center, George Mason University)

Presentation Title: CD: Developing a Data-Oriented Human-Centric Enterprise Architecture for EarthCube


  • Project Objective: EarthCube as defined in 2012 is expected to act as research engine, resource management platform, computing service provider, and education platform.

    • Benefit: the design results will become a reference framework.

  • Spiral approach with 4 “checkpoints”:

    • Spiral 1: 10% of all requirements.

    • Spiral 2: 50% of all requirements.

    • Spiral 3: 80% of all requirements.

    • Spiral 4: 100% of all requirements.

  • Progress so far: Spiral 1 started in 2013, and there are activities in the first 3 spirals with most activities completed for Spiral 1.

  • Science Driver: Initial design is based on user requirements of data, information, or computing resource.

  • EarthCube EA Reference and Architecture document have been completed.

  • Capabilities: 3 parts - end user, enabling, and resource (different categories of users contribute to the requirements of these 3 types of capabilities).

  • Services: several services have been completed with many more on the way.

  • End User Operations: Examples presented are resource discovery activity and governance activity.

  • Next Steps: refine the ontology, dictionary structure and complete the volume at a certain level; focus on an example to demonstrate how to use the enterprise architecture design; integrate with EarthCube reference architecture; formalize the output and make it open access for the benefit of the Geoscience communities; continue to engage communities.

  • Next EA Design workshop will be one of the days during ESIP Summer Meeting (July 14-17, 2015).


Speaker 4: Daniel Pilone

Presentation Title: EarthCube Conceptual Design, a SCalable commUnity Driven ARchitecture (SCUDAR)


  • Process: major steps are - identification, development, capture, and generation.

  • Focused on the core issues that need to be addressed in terms of EarthCube Challenges & Needs: mainly, wildly diverse data; heterogeneity of data sources/format/distribution mechanisms/etc; interoperability and community use of data is critically important; and highly sophisticated desired use cases.

  • The fundamental: Existing data needs to be searchable and discoverable in EarthCube.

  • Data Provider, EarthCube CI, Data Analysis are the 3 major components of the architecture.

  • “Interoperability is Key,” “Model Drive Information Architecture,” “Iteration and Evolution” are the additional design guidelines.

  • Capturing and Communicating: TOGAF approach - processes; data/information model; application architecture, and technology architecture.

  • Topics Discusses: Core, prioritized use cases; drivers and architectural principles; federated vs centralized architecture; governance models; mobility of computation and services; commitment to infrastructure management and sustainment; deployment model and support for integrating building blocks.

  • More updates will be available in May.



  • Each of the architecture has its viewpoint, but these viewpoints do not necessarily match.  It might be good to review these viewpoints and their similarities/differences.

    • This review might be helpful in comparing the different architectural approaches.

  • High level components for the framework might need to be defined/clarified.

  • Review of the use cases/building blocks and the information from the reviews should be made available for other.

  • How can the information regarding the architectural designs be made publicly available?

  • What are the key ways to test the designs?

    • Groups responsible for use cases and testbeds should be collaborating, so that the designs could be tested accordingly.

  • Radical thought: EarthCube already exists (based on the current systems); EarthCube evolution should be about the integration of these systems?

    • Related question: How to integrate data from different types?

  • Even though that there are a lot of existing capabilities, they might not all meant or have the same aim to serve the purpose and scope of EarthCube.  As a result, it is still important to evaluate the architecture/capabilities/components, etc with EarthCube’s focus in mind.

  • Policies/processes to produce a framework might be one of the most valuable outcome.
Richard, S.; EarthCube Architecture; Winter Meeting 2015. ESIP Commons , December 2014