Introduction..... 3 Data Model s Role in DaaS....3 The SQL Azure Use Case.......4 Best Practices and Guidelines.......5 Conclusion...... 9 Glossary.....9 References.....10 About the Author.....10 PAGE 2
Cloud computing is one of the major growth areas in the world of IT. This article provides an analysis of how to apply the DaaS (Database as a Service) lifecycle working with ERwin and the SQL Azure platform. It should help enterprises to obtain the benefits of DaaS and take advantage of its potential for improvement and transformation of data models in the Cloud. The Use Case introduced identifies key actions, requirements and practices that can support activities to help formulate a plan for successfully moving data to the Cloud. Data models play a central role in defining, managing and protecting data in Cloud computing services. Modeling is the key guideline in a DaaS architecture and Model as a Service (MaaS) increases the efficiency of defining, updating and sharing data models and database designs. In DaaS, data models are the most efficient way to offer customers, as well as providers, visibility, agility and secure database updates. As a consequence, models can be considered on-premise databases because they collect behaviors, documents and information concerning structures, access rights, security and database scaling, partitioning and evolution. In other words, models ensure that the behavior and effectiveness of the released Cloud applications can be measured and tracked to meet SLA and DaaS contract constraints. Models leverage Cloud database services to enable flexible deployment and therefore enforce persistence, storage and geo-location policies throughout the Cloud. Models provide preconfigured DaaS properties. Especially when MaaS is applied, data models help meet Cloud service directives. In detail, looking at Figure 1, we might define two operational areas: 1. The left scenario, the On-premise Design Zone, is common to both Customers and Providers. Here, data models simplify the designing, tracing and updating of databases. Ordering on-premise models and database architectures should be the primary goal for all companies, especially when they are moving in the direction of the Cloud. Through the data model, properties such as service security range, DB partitioning and scaling, multi-tenancy, geo-location and all requested assets are defined early in the DaaS lifecycle. The Design zone satisfies the following condition: Do not bring your database confusion to the Cloud first make sure it is correct on-premise ; Figure 1: ERwin Data Modeler supports DaaS Lifecycle PAGE 3
2. The area on the right side in Figure 1 is the provisioning and deployment zone. Multiple on-premise databases can be scaled up or down based on business needs. Models provide continuity with the databases structure to extend to the Cloud preconfigured levels of security, compliance and what has been registered inside the data models. The right zone should be managed by a database service hosted platform fed by data models. Models should always be the main reference throughout the lifecycle and provide operational input to the DaaS states. Both zones are independent although they are integrated and kept in symmetry. The MS SQL Azure platform covers the provisioning and deployment role. DB symmetry, host synchronization, auto high availability and fault tolerance are the main tasks the MS SQL Azure platform satisfies. Models coming from different databases can manage the DaaS lifecycle along the DaaS lifecycle s states. Getting practice with ERwin and the MS SQL Azure platform means explaining how to apply the DaaS lifecycle to realize faster and positive impacts on the go-live preparation with Cloud services. The following Use Case will introduce the operational DaaS practices and translate them into the appropriate guidelines. Therefore, the DaaS service considerations we are looking for are: 1. Differentiation or creating competitive advantage; 2. Compliance and risk, i.e. awareness of the business operational context and threats; 3. Cost/Operational Excellence, creating competitive advantage through efficiencies and effectiveness. Applying DaaS with Microsoft SQL Azure implies trying to find the optimal zone where the ERwin model best maps the DaaS requirements at a given infrastructure with respect to the three considerations above. Given a data model, MaaS helps in satisfying the DaaS requirements. Figure 2: An example of how models provide early DaaS optimal scaling and provisioning Relating to compliance and risks, we assume that ISO 27001-2005 and SAS70 are good policies to start Cloud Regulation and to audit DaaS. SQL Azure covers DaaS requirements and is compliant with the DaaS lifecycle. In Figure 2, the diagram shows SQL Azure and ERwin working together along the DaaS lifecycle: PAGE 4
Figure 3: ERwin and SQL Azure support DaaS To better explain the integration provided, we use MIBU to specify what should be the interaction along the states of the above lifecycle. Models provide preconfigured service properties. As a consequence, ERwin and SQL Azure supply, on one hand, a preconfigured and operational databases target image and, on the other hand, the details of how to enable provisioning and deployment of multiple databases. The Use Case we are introducing traces the whole DaaS lifecycle by underlining interaction and functionalities respectively for ERwin and the SQL Azure platform. The states of the Use Case are defined as follows: Create DB Model ERwin s reverse engineering from existing databases allows data models to feed the DaaS lifecycle. This feature, applied together with MaaS, is a powerful opening to supply physical data models that might be a priori closer to the target infrastructure. In fact, data models contain information and properties about the deployed databases and partitioning architecture: Model partitioning is a pre-definition of persistence conditions in a SQL Azure deployment. The model contains location constraints specifying where data should be stored. In case of data retrieval, contract expiration or data breaching, the database architecture and partitioning are defined at the model level; Querying and aggregation are defined in the model. SQL Azure can set synchronization and symmetry rules based on ERwin querying. Any breach by an external query or aggregation not defined in the model is immediately a rule violation in SQL Azure, and as such, a possible data violation. Inference is defined in the model as well and set by SQL Azure in the same way; When creating data models, properties for confidentiality, availability, authenticity, authorization, authentication and integrity are defined. SQL Azure can inherit and deploy all ERwin model security properties through the infrastructure; Models contain configuration and administration properties; partitions define DBMS deployment, hardening, machines, scripts and stored procedures. Database forward/reverse engineering is continually updated as the DBMS changes. SQL Azure inherits the ERwin DBMS configuration and administration and accepts changes during the DaaS lifecycle. PAGE 5
Figure 4: MIBU Create DB Model high level ERwin/ SQL Azure interface Generate/Update DB ERwin provides automatic database generation and synchronization that helps users in revising the model and its properties. ERwin is the preliminary hub for SQL Azure. Data models meet all service requisites and database properties to set rules and prepare database provisioning and deployment. In the Generate/ Update state of the DB DaaS lifecycle, reliability and security features are verified and updated together with data infrastructure and data protection constraints. Fig. 5 MIBU Generate/Update DB high level ERwin/SQL Azure interface Populate, Use and Test DB ERwin supplies platform-specific database designs that have been run and tested to the SQL Azure environment : Models represent defined maps of data. This allows remote tests to be regularly performed to discover deployed data. Therefore, SQL Azure inherits from ERwin a preconfigured service topology needed to document regulatory authority compliance; ERwin queries and aggregation tests become SQL Azure platform rules. This also helps in assuring data and regulatory authority compliance along the target infrastructure; PAGE 6
Application monitoring and optimization classify an object s logic and level controls defined when creating the model. Here it is important that models are DBMS-specific so object level controls are the appropriate ones. The SQL Azure platform inherits an object s logic and level controls to be applied to the Cloud database deployment; ERwin monitors application logic. The SQL Azure platform/erwin data model symmetry allows continuous logic and contents improvement to the Cloud service. Figure 6: MIBU Populate, Use and Test DB high level ERwin/SQL Azure interface Deploy & Share This state is concerned with a target deployment at the Provider site. The ERwin model created for SQL Azure contains all of the necessary information to secure an assisted deployment: The SQL Azure deployment is guided from model properties and architecture definition. Discovery and geo location are always available when asked for, in alignment with SQL Azure functionality; In ERwin, the map of data is defined and updated, checking whether the infrastructure provider has persistence and finding out whether outages are related to on-line tasks; Controls for SQL Azure database deploying and sharing are guided from model properties and architecture definition. Figure 7: MIBU Deploy & Share high level ERwin/SQL Azure interface Archive & Change This phase is the heart of the life cycle. Changes, updates and possible deletion cannot be set without regular versioning and snapshot comparison management: Updates are registered and archived at the customer site. Deletions and restores are guided by the customer DB compare and approval. SQL Azure synchronizes any future change in the data models; Backups are registered and archived at the customer site. Versioning on the trunk and branches are supervised by the customer; PAGE 7
Outage is covered by versioning and change archives based on partitioning. SQL Azure content discovery assists in identifying and auditing data to restore the service to previous versions. SQL Azure rules for defined downtime determine timing and costs; Figure 8: MIBU Archive & Change high level ERwin/SQL Azure interface Figure 9: MIBU Secure Delete high level ERwin/SQL Azure interface Secure Delete Data has to be destroyed as necessary. The model contains all properties to conduct this activity for both partial or final deletions: According to information and properties defined in the Create DB Model state, procedures for removal for effectively destroying data wherever it resides must be available. Location constraints defined in the model identify persistent storage for retrieving and deletion. SQL Azure executes the destroying operation on the basis of ERwin data model properties. The path outlined above can be summarized looking at Figure 10. Here is the full DaaS model-driven lifecycle and the actors executing each subset of actions applied in the Use Case. PAGE 8
Figure 10: DaaS Life Cycle applied through the SQL Azure platform Organizations planning to move to the Cloud need to maintain visibility of their existing data structures and systems, especially when Cloud data applications are created, deployed, shared, changed and, if necessary, destroyed. Security is the highest priority in sharing data through the Cloud. Data models drive the DaaS life cycle, ensuring that all properties belonging to the data models are registered, updated and geo-located. The Microsoft SQL Azure hosting infrastructure supplies high availability and fault tolerance in moving and migrating databases to the Cloud and assists with web deployment and administration. Starting from on-premise data model designs, customers can have an understanding of Cloud database partitioning, scale changes, multi-tenant assets, data center geo-locations and contract constraints. Data models begin and preserve the entire Database as a Service (DaaS) life cycle while the MS SQL Azure platform deploys database applications as a hosted service in the Cloud. CapEx: Capital Expenditure; DaaS: Database as a Service. We must note that the NIST (National Institute of Standards and Technology) accepts the acronym DaaS to specify Data as a Service. Since cloud computing acronyms are growing rapidly in quantity and meaning the NIST is trying to apply standard naming; HUB: Multi-port repeater device; ISO 27001-2005: ISO/IEC 27001, part of the ISO/IEC 27000 family of standards, is an Information Security Management System (ISMS) standard published in October 2005 by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO/IEC 27001:2005 specifies a management system that is intended to bring information security under explicit management control. Being a formal specification means that it mandates specific requirements. Organizations that claim to have adopted ISO/IEC 27001 can therefore be formally audited and certified as compliant with the standard. MaaS: Model as a Service; PAGE 9
MIBU: Modeling ITIL by UML; OLA: Operational Level Agreement; OpEx: Operational Expenditure; SaaS: Software as a Service; SAS70: Statement on Auditing Standards No.70 (SAS 70) is an internationally recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA) in 1992. It is used to report on the "processing of transactions by service organizations", which can be done by completing either a Type I or a Type II audit. A SAS 70 Type I audit refers to "reporting on controls placed in operation", while a SAS 70 Type II audit refers to "reporting on controls placed in operation" and "tests of operating effectiveness". SLA: Service Level Agreement I sincerely thank Donna Burbank for her precious feedback, encouragement and availability on publishing the fourth paper of the series [1] N. Piscopo - ERwin in the Cloud: How Data Modeling Supports Database as a Service (DaaS) Implementations http:// erwin.com/whitepapers/detail/erwin_in_the_cloud_how_data_modeling_supports_database_as_a_service_daas_im/ [2] N. Piscopo - CA ERwin Data Modeler s Role in the Relational Cloud http://erwin.com/whitepapers/detail/ ca_erwin_data_modelers_role_in_the_relational_cloud/ [3] N. Piscopo - https://www.ca.com/us/collateral/white-papers/na/best-practices-for-moving-to-the-cloud-using-data- Models-in-the-DaaS-Life-Cycle.aspx [4] D. Burbank, S. Hoberman - Data Modeling Made Simple with CA ERwin Data Modeler r8, Technics Publications, 2011 [5] I. Jacobson, I. Space, K. Bittner - Use Case 2.0 ebook. [6] N. Carr - The Big Switch www.nicholasgcarr.com/bigswitch [7] C. Anderson - The Long Tail http://thelongtail.com/about.html Nuccio Piscopo has more than 20 years in the IT industry as a Data and Application change management technical executive, with a University Degree in Physics, post laurea from the International School of Physics Enrico Fermi, as well as a post laurea Master in Information Engineering (Computer Science). At present Nuccio is an independent consultant delivering SaaS, DaaS designing, startup, education and contracting consultancy, and cloud audit risk assessment for customers migrating to the Cloud. In previous roles, Nuccio served at IR Semiconductors, Kraft, Bachmann/Cayenne, Platinum Technology and CA Technologies. Nuccio Piscopo can be contacted through http://it.linkedin.com/in/nucciopiscopo. Copyright 2012 CA. All rights reserved. Microsoft, Microsoft SQL Azure, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. All other trademarks, trade names, service marks and logos referenced herein belong to their respective companies. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. This document is for your informational purposes only. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document as is without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or noninfringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, business interruption, goodwill or lost data, even if CA is expressly advised in advance of the possibility of such damages. PAGE 10