<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Big Data Science Architecture for Continuous Technology Transfer from Research to Industry Operations</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Richard A. E. Leibrandt</string-name>
          <email>richard.leibrandt@widas.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>WidasConcepts Unternehmensberatung GmbH</institution>
          ,
          <addr-line>Maybachstrae 2, 71299 Wimsheim</addr-line>
          ,
          <country country="DE">Deutschland</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Big Data without analysis is hardly anything but dead weight. But how to analyse it? Finding algorithms to do so is one of the Data Scientist's jobs. However, we would like to not only explore our data, but also automatise the process by building systems that analyse our data for us. A solution should enable research, meet industry demands and enable continuous delivery of technology transfer. For this we need a Big Data Science Architecture. Why? Because in Big Data Science (BDS) projects, Big Data (BD) and Data Science (DS) { in uencing each other { can't be handled separately. Thus, their complexities (and gain) multiply: BDS 6= BD+DS, BDS = BD DS. This complexity boost increases further by the clash of the two di erent worlds of scienti c research programming (DS) and enterprise software engineering (BD). The former thrives on explorative experiments which are often messy, ad hoc and uncertain in their ndings. The later requires code quality and fail-safe operation, achieved by well de ned processes with access control and automated testing and deployment. We present a blue print for a Big Data Science Architecture. It includes data cleaning, feature derivation and machine learning, using Batch and Real-time engines. It spans the entire lifecycle with three environments: Experiments, close-to-life-tests, life-operations, enabling creativity while ensuring fail-safe operation. It takes the needs of data scientist, software engineers and operation administrators into account. Data can be creatively explored in the experimental environment. Thanks to strict read governance no critical systems are endangered. After algorithms are developed, a technology transfer to the test environment takes place, which is build the same as the life-operations environment. There the algorithm is adapted to run in automated operations and tested thoroughly. On acceptance the algorithms are deployed to life-operations.</p>
      </abstract>
      <kwd-group>
        <kwd>Big Data</kwd>
        <kwd>Data Science</kwd>
        <kwd>Architecture</kwd>
        <kwd>Industrial Challenges</kwd>
        <kwd>Technology Transfer</kwd>
        <kwd>Continuous Delivery</kwd>
        <kwd>Batch- and Real-Time-Processing</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body />
  <back>
    <ref-list />
  </back>
</article>