MaaS (Model as a Service) sets a new concept to order and classify data modeling design and deployment to the Cloud. MaaS changes the way to move data to the Cloud because allows to define data taxonomy, size and contents. Starting from data model design, MaaS might guide the DaaS (Database as a Service) lifecycle, providing data granularity and duty rules: as a consequence, MaaS implements the new concept of Small Data.

In fact, Small Data answers to the need of controlling “on-premise” data dimension and granularity. Anyway, Small Data is not data volume limitation. Small Data affords data modeling full configuration and provides 2 main advantages: data model scale and data ownership that provide assigned data deployment and, finally, data deletion in the Cloud.

Introduction
The inheritance coming from the past imposes to manage big data as a consequence of multiple integration and aggregation of data systems and data movement. Data coming from Social Networks intensive data applications have contributed to blow up the EB containers.

Administrating big data is not an option but rather a debt contracted above all with the data management history. Anyway, Big Data analytics seems to be a standard practice in storing massive data. Is there any way to change this norm? Companies have for many years used data models by designing and mapping data, started the change and today manage the “tiller” of their data heritage.

Accordingly, Small Data is far from a further catch-phrase: the antonyms with respect Big Data aims to pay attention in changing mind and using data models to design fit, noticeable data systems, especially when data are moved to the Cloud. MaaS implements Small Data, enables Personal Cloud and help to recover, to order and to classify, data inheritance of the past as well.

Why MaaS defines and implements Small Data
MaaS meets the ever-increasing need for data modeling and provides a solution to satisfy continuity of data design and application. Further, it helps in choosing and defining architectures, properties and services assets looking at the possible evolution and changes the data service can have. MaaS meets scaling and dimensioning in designing data systems, supports scalability and, in particular, agile data modeling appliance. Small Data starts when the dimension of the data system has to be defined and controlled since the description (metadata). In effect, we are improperly speaking of data systems: actually, we are dealing with data services. The Cloud is the great supplier of data services.

Since MaaS allows defining “on-premise” data design requirements, data topology, performance, placement and deployment, models themselves are the services mapped in the Cloud. In fact, data models allow to “on-premise” verify how and where data has to be designed to meet the Cloud service’s requisites. In practice, MaaS enables in designing the data storage model. The model should enable query processing directly against databases to strengthen privacy levels and secure changes from database providers;

- Modeling data to calculate “a priori” physical resources allocation. How many resources does the service need? Do database partitions influence resource allocation and/or replication? Modeling the data means designing the service; calculating a priori these magnitudes drives both deployment and database growth;

- Modeling data to predict usage “early” and to optimize database handling. Performance and availability are two of the main goals promised by the Cloud. Usage is not directly dependent upon the infrastructure and, as a consequence, could be a constraint. Calculating the usage rate means understanding the data application life cycle and then optimizing the data service properties;

- Designing multi-data structures to control databases elasticity and scalability. Models contain deployment properties and map the target database service. Therefore, the model designs “on-premise” database elasticity and scalability. Still, we will see later that multi-database design is a way to control data persistence.

Thus, imagine we have users asking for temporary services to be deployed and, after services have been closed, cancelled. Services satisfying these requirements are based upon data models designed by MaaS agile model techniques, controlled size and contents, fast update, rapid testing and continuous improvement forward the generation of the model/dataset to the target database. Models should set users’ data contents, dimension (for example, to suit to mobile services), data deployment (geo-location, timing …) and to be, on-demand, definitively destroyed.

With MaaS, Small Data can be defined since the metamodel design and then implemented, synchronized and deployed to the target by applying the DaaS lifecycle. Of course although, Small Data are placed under size and content control, they can be created and replicated infinitively: is this a further way to switch to Big Data again?

The following aspects would be considered:

1) Users should be enabled to destroy their Small Data in the Cloud when the service is over. This is a great feature for data security. Still, data navigation changes from infinite chains to point-to-point gaps (or better “Small to Small” Data) based upon Small Data models definition;

2) Time limit could be set or an over storage timing strategy might be defined for Small Data allocation in the Cloud;

3) Statistically speaking, by applying Small Data the average of data storing coming from intensive data applications (Social Networks, for example) should be computed and standard deviations estimated due to multiple storage allocation and, above all, free.

This doesn’t mean the YB is the last order of magnitude of data size the SI has defined. Definitively, MaaS enables service designers to plan, create and synchronize Small Data models from and to any web data source and data management system in the Cloud. Data granularity changes and enables designers to calibrate data models and data services by defining model’s content that allows users to deploy i.e. allocate and then, at the end of the service, to shred the data in the Cloud. This is a new frontier for Mobile services, Open Data and what today might be defined as Personal Cloud.

MaaS enables Personal Clouds
What is really new in the Small Data definition is the likelihood to move the data ownership from big players to users and, as a consequence, place under relation ownership and deployment location. Today data storage is almost under provider full control. Providers and storage players manage data users and data security. By applying MaaS, Personal Cloud is enabled and following here is what change:

1) Integrity defined into MaaS at the Small Data level is maintained through the service. Ownership matches the data structure/dataset deployed;

2) MaaS identifies trust boundaries throughout the IT architecture. Data models are the right way to define trust boundaries and ownership to prevent unauthorized access and sharing in “Small to Small” Cloud storage and navigation;

3) MaaS enables to set location in the data model. Any mismatch could be an infringement and must be reconciled with the terms registered in the Small Data design. Point to point navigation based upon Small Data simplifies Personal Data management and maintenance: this aspect has a positive impact on data storage order and security;

4) Ownership and data location are linked by relation. Once Personal Data in the Cloud has to be deleted, the Cloud Provider should assure the data are unrecoverable. Looking at data model mapping, data has to be destroyed in the location defined in the Small Data design. Data owners know where the data has been deployed because before opening the data service in the Cloud they may accept or not the location assigned and might ask for a new storage site.
Personal Cloud has large ranges of applications:

1) Mobile services in single/multiple personal storage by single/multiple dataset in the Cloud;

2) Healthcare services as introduced, for example, in [10] and in [11];

3) Open Data services, especially when they are interfaced to the above 1) and 2) services;

4) HR services, mainly when they concern curricula content. Owners should be free to definitively cancel personal data as defined in Small Data designing;

5) Generic personal data in the Cloud regardless they are permanent or temporary stored.

Applying MaaS, Small Data can be considered on-premise services because they collect behaviours and information concerning structures (to be deployed in the Cloud), access rights, security and scaling, partitioning and evolution. In other words, Small Data ensure that the behaviour and effectiveness of the released Cloud applications can be measured and tracked to meet user’s needs. Models leverage Cloud data services to enable flexible deployment and therefore enforce Personal Data persistence, storage and geo-location policies throughout the Cloud.

Conclusion
Big Data is a consequence, Small Data is a new start. MaaS provides Best Practices and guidelines to implement Small Data and Personal Cloud ownership by starting from data modeling and DaaS lifecycle. We want to underline that Big Data as we know is a consequence of how companies have for many years used, stored and maintained data. Small Data indeed might be a new way to manage data in the Cloud. Especially when personal data are considered, Personal Cloud provides, on one hand, a preconfigured and operational data definition (for example, local information vs. cloud information) and, on the other hand, the details of how to enable provisioning and deployment of multiple storage in the Cloud. Finally, starting from “on-premise” Small Data design, Personal Cloud can be applied and users can have soon an understanding of Cloud deployment, data centre geo-locations and service constraints.

Glossary
Big Data – Collection of datasets cannot be processed (analysis, storage, capture, search, sharing, visualization …) using on-hand database management tools or traditional data processing applications. It is due to data complexity, data amount and fast growth;
EB – Exabyte, unit of information or computer storage equal to one quintillion bytes (1018 bytes);
DaaS: Database as a Service;
MaaS: Model as a Service is a trade mark (MaaSTM);
SI – Système International d’unités metric prefix ;
YB – Yottabyte, unit of information or computer storage equal to one septillion bytes (1024 bytes).

References
[1] N. Piscopo – ERwin® in the Cloud: How Data Modeling Supports Database as a Service (DaaS) Implementations
[2] N. Piscopo – CA ERwin® Data Modeler’s Role in the Relational Cloud
[3] D. Burbank, S. Hoberman – Data Modeling Made Simple with CA ERwin® Data Modeler r8
[4] N. Piscopo – Best Practices for Moving to the Cloud using Data Models in the DaaS Life Cycle
[5] N. Piscopo – Using CA ERwin® Data Modeler and Microsoft SQL Azure to Move Data to the Cloud within the DaaS Life Cycle
[6] N. Piscopo – MaaS (Model as a Service) is the emerging solution to design, map, integrate and publish Open Data http://cloudbestpractices.net/2012/10/21/maas/
[7] N. Piscopo – MaaS Workshop, Awareness, Courses Syllabus
[8] N. Piscopo – DaaS Workshop, Awareness, Courses Syllabus
[9] N. Piscopo – Applying MaaS to DaaS (Database as a Service) Contracts. An introduction to the Practice http://cloudbestpractices.net/2012/11/04/applying-maas-to-daas/
[10] N. Piscopo – MaaS applied to Healthcare – Use Case Practice, http://cloudbestpractices.net/2012/12/10/maas-applied-to-healthcare/
[11] N. Piscopo – MaaS and UMA implementation at page 16 in Transform2:, http://cloudbestpractices.files.wordpress.com/2013/01/transform-203.pdf
[12] Agile Modeling – http://www.agilemodeling.com/

Disclamer
“MaaS implements Small Data and enables Personal Clouds” (the Document) is provided AS-IS for your informational purposes only. In no event the contains of the document will be liable to any party for direct, indirect, special, incidental, economical (including lost business profits, business interruption, loss or damage of data, and the like) or consequential damages, without limitations, arising out of the use or inability to use this document or the products, regardless of the form of action, whether in contract, tort (including negligence), breach of warranty, or otherwise, even if an advise of the possibility of such damages there exists. Specifically, it is disclaimed any warranties, including, but not limited to, the express or implied warranties of merchantability, fitness for a particular purpose and non-infringement, regarding this document or the products’ use or performance. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies/offices.