System Design Document Template, Lecture notes of Design

Download System Design Document Template and more Lecture notes Design in PDF only on Docsity!

Atlanta Regional Commission – MSAA

System Design Document

Document Number : 10.

Federal Award ID Number : GA- 26 - 0008 - 01

System Design Document Table of Contents

SDD Version 4.0 ii ARC SGT SDD>

System Design Document List of Figures

System Design Document List of Tables

• 1. Introduction Table of Contents
  • 1.1 Purpose of the SDD
  • 1.2 Audience
  • 1.3 Executive Summary
    • 1.3.1 System Overview Summary
    • 1.3.2 Design Constraints
    • 1.3.3 Future Contingencies................................................................................
    • 1.3.4 Document Organization
• 2. General Overview and Design Guidelines/Approach
  • 2.1 General Overview
  • 2.2 Current
    • 2.2.1 Proposed Solution - Statement of Need
  • 2.3 Stakeholder Roles/Responsibilities/Concerns
    • 2.3.1 Roles
    • 2.3.2 Responsibilities
    • 2.3.3 Concerns
  • 2.4 System Assumptions/Constraints/Dependencies/Risks
    • 2.4.1 Assumptions
    • 2.4.2 Constraints
    • 2.4.3 Dependencies
    • 2.4.4 Risks
      • Alignment with National/Regional ITS Architectures
• 3. Design Considerations
  • 3.1 Goals and Guidelines......................................................................................
  • 3.2 Operational Environment
  • 3.3 Development Methods & Contingencies
  • 3.4 Architectural Strategies
  • 3.5 Performance Engineering
• 4. System Architecture and Architecture Design
  • 4.1 System Architecture Diagrams........................................................................
    • 4.1.1 External Systems diagram
    • 4.1.2 Functional/Logical diagram
  • 4.2 Hardware Architecture
    • 4.2.1 Security Hardware Architecture
    • 4.2.2 Performance Hardware Architecture.........................................................
  • 4.3 Software Architecture......................................................................................
    • 4.3.1 Software Elements....................................................................................
    • 4.3.2 Security Software Architecture
    • 4.3.3 Performance Software Architecture
  • 4.4 Information Architecture
    • 4.4.1 Records Management SDD Version 4.0 iii ARC SGT SDD>
  • 4.5 Internal Communications Architecture
  • 4.6 Security Architecture
  • 4.7 Performance
• 5. System Design
  • 5.1 Business Requirements
  • 5.2 Database Design 5.1.1 Priorities Error! Bookmark not defined.
    • 5.2.1 Data Objects and Resultant Data Structures
    • 5.2.2 File and Database Structures
  • 5.3 Data Conversion
  • 5.4 User Machine-Readable Interface
    • 5.4.1 Inputs
    • 5.4.2 Outputs
  • 5.5 User Interface Design
    • 5.5.1 Section 508 Compliance
• 6. Operational Scenarios
• 1.1 Major Operational Scenarios
• 1.2 Major Use Cases
  • 1.2.1 Customer Resources
  • 1.2.2 Vehicle Resources
  • 1.2.3 Driver Resource
  • 1.2.4 Reservations
  • 1.2.5 Scheduling
  • 1.2.6 Dispatch
  • 1.2.7 Analytics
• 7. Detailed Design
  • 7.1 Hardware Detailed Design
  • 7.2 Software Detailed Design
  • 7.3 Security Detailed Design
  • 7.4 Performance Detailed Design
  • 7.5 Internal Communications Detailed Design
• 8. System Integrity Controls
• 9. External Interfaces
  • 9.1 ATL Transit
  • 9.2 Google Maps
  • 9.3 OpenTripPlanner.............................................................................................
  • 9.4 Rideshare
  • 9.5 Taxi Fare Finder..............................................................................................
  • 9.6 Transportation Network Companies (TNC)
  • 9.7 GTFS Real Time SDD Version 4.0 iv ARC SGT SDD>
  • 9.8 GTFS Flex
  • 9.9 Emerging Business Models
  • 9.10 Third Party Commercial Application Integration
  • 9.11 Transportation Clearinghouse
    • 9.11.1 Adapter API
  • 9.12 Points of Interest
  • 9.13 Public Transit
  • 9.14 GTFS
  • 9.15 Agencies
  • 9.16 Specialized Service Providers
  • 9.17 Providers
  • 9.18 Services
    • 9.18.1 Geocoding
    • 9.18.2 Maps
    • 9.18.3 Google Street View
  • 9.19 Interface Architecture
  • 9.20 Interface Detailed Design
• 10. Appendix A: Record of Changes
• Figure 1: SGT Roles...................................................................................................... List of Figures
• Figure 3: Amazon Web Services model
• Figure 4: External systems diagram
• Figure 5: Hardware architecture
• Figure 6: Security architecture
• Figure 7: Software architecture tiers..............................................................................
• Figure 8: SGT high level architecture
• Figure 9: Security authentication
• Figure 9: Performance architecture scalability
• Figure 11: Example of a database design
• Figure 12: Example of balsamiq mockup
• Figure 13: Example of web application hosting
• Figure 14: Security detail design
• Figure 14: Sample uber API responses......................................................................... SDD Version 4.0 v ARC SGT SDD>
• Table 1: Project members contact information List of Tables
• Table 2: System design roles
• Table 3: Software descriptions
• Table 4: Systems descriptions
• Table 5: Server requirements
• Table 6: Software elements and descriptions
• Table 7: SGT future enhancements
• Table 8: Data objects and schemas
• Table 9: Major operational scenarios
• Table 10: Customer use cases
• Table 11: Vehicle use cases
• Table 12: Driver resource use cases
• Table 13: Reservation use cases
• Table 14: Schedule use cases
• Table 15: Dispatch use cases
• Table 16: Report use cases
• Table 17: 1-Click Points of Interest File Format
• Table 18: Public Transit Agency Attributes
• Table 19 - Specialized Services Provider Attributes
• Table 20: Provider Services attributes...........................................................................
• Table 21: Map API pros & cons
• Table 22: Record of changes

The project was funded through a Veterans Transportation and Community Living Initiative (VTCLI) grant of the Federal Transportation Administration (FTA) as part of their “One-Click/One-Call” initiative. Launched on March 2015, Simply Get There became the first comprehensive online trip planner for HST populations in the Atlanta region. 1.1 Purpose of the System Design Document (SDD) The SDD documents and tracks the necessary information required to effectively define architecture and system design in order to give the development team guidance on the architecture of the system to be developed. Design documents are incrementally and iteratively produced during the system development life cycle, based on the particular circumstances of the information technology (IT) project and the system development methodology used for developing the system. Cambridge Systematics is the original developer of the current solution. The intent of the solution was to provide a “one call one click” solution. This was not achieved in the initial implementation. The initial vision of the Regional Mobility One-click software application was to link multiple existing call centers to one centralized database with a multi-functional web interface. This concept would maximize staff resources and make transportation information accessible to a wider range of consumers. Transportation resources would be available to the general public and to participating call center operators. Call center staff would have access to a secure client component of the application to register consumers and assist them in accessing/scheduling services. The system would provide an interface for existing client and transportation resource databases from ESP and atltransit.org. The proposed solution will simply add additional features and functionality to the existing solution to meet the original scope and vision of the Regional Mobility One Click Software application. These features will extend SFT to be a real and integrated one call – one click mobility management solution. Key points that relate to the design and architecture of the proposed system.

1. No major changes to existing architecture
2. No major changes to system design
3. Major positive impact to the user community
4. Major feature extensions to automate operational functions
5. Major feature extensions to coordinate multiple call centers and transportation providers
6. Regional Coordination API Middleware development Based on extensive user interviews conducted during the concept of operations phase, it was revealed that the current solution is lacking in key features. It provides strong multi-modal trip planning functions but is limited in back office operational features and lacks one call one click functionality for the consumer. Simply Get There will be expanded to include to create a true one call one click center. The following additional major functionality that users requested to be added or improved include:

• Web-Based Reservations
• Automated Scheduling
• Provider Management
• Trip – Provider Assignment
• Automated Dispatching
• Regional Transportation Coordination
• Regional Cost Allocation

• Automated Fare Payment
• Mobility on Demand Mobile App for consumers and operators 1.2 Audience The intended audience for the SDD is the project manager, project team, and the future development team. The audience or users for this system design document include the following:
• ARC Project Management Team
• ARC Information Technology Team
• Future application development team
• FTA Project Managers and Oversight Team
• Internal Consulting Team 1.3 Executive Summary 1.3.1 System Overview Summary ARC has entered a cooperative agreement with FTA to create system specifications for a web-based application that will bring the system forward from “trip discovery” (pinpointing options) to “trip transaction" (centralized booking, scheduling, and dispatching). ARC staff will work with Ride Connection and the third party consultants to design this application. ARC plans to issue an RFP for competitive procurement. As with websites like kayak.com that aggregate airline data, the long-range vision is for residents to book trips through one online web application, ideally supplemented with phone services. This concept and application design will include the entire process of establishing eligibility, scheduling a trip, finding the right transportation mode and provider, executing the trip, and invoicing the client and paying the provider, as applicable. The application must be designed to be intuitive, supportable, scalable, cost effective, and have the foundation to support future growth. It should also be user-friendly for the general public, transportation and service providers, and ARC staff. ARC has developed an extensive network of external partners and may want to grow or extend the network over time. These partners may wish to access the information directly through a user interface or through an API into their own client system. ARC must have a hierarchy of access points within the application’s administrative functions so that ARC may select the level of access for various external partners. Project goals include:

1. Integration with Simply Get There trip discovery web application
2. Ability to create client profiles with permissions to use multiple providers, records of current eligibility, trip accommodations needed, and indication of other programs they might join
3. "Trip triaging” capabilities to find ideal cost/accommodations match
4. Ability to schedule a trip
5. Ability to pay for a trip
6. Ability for ARC or a provider to charge a user and for ARC to pay a provider
7. Information on and ability to schedule travel coaching/training assistance
8. Cross-modal trip booking and connections to manifest creation and scheduling systems as well as route optimization across modes
9. Payment and billing - Cost sharing calculated on back-end
10. Data analysis/monitoring to find efficiencies and influence planning/future implementation in a system-wide feedback loop
11. Modular system (“plug and play” system that users could adapt to local needs)
12. Integration with third party systems, including Computer- Aided Dispatched /Automatic Vehicle CAD AVL software, Google, Google Maps, RouteMatch, and Trapeze
13. Ability to track trips by the funding source
14. Ability to generate invoices

1.3.2 Design Constraints The proposed solution will utilize the current architecture and system design of the current solution. The current solution is hosted in an industry leading application hosting and data center. Performance, storage, security, and access can be easily scaled using to meet the minimal amount of additional resources the proposed solution will require. This will be a financial constraint that must be considered. Financial The largest design constraint for the implementation of the project is financial. The full implementation of the project could be financially significant. ARC intends to implement a phased approach to manage this constraint. Technical The development and integration of the new software components into the existing open source software application is a major constraint. Specifc skills and technical understanding of mobility management and demand response management and optimization will be required. This knowledge and skillset is very specific and narrow. Detailed business requirements and use cases will assist in minimizing this challenge. Transportation coordination and trip sharing will be a major technical consideration. The proposed system must support regional coordination features and provide the ability to integrate trip data into other scheduling and dispatching systems. The coordination function must allow for easy integration and provide open published API’s. Due to the fact that the application is currently hosted and managed by ARC staff, we do not envision any technical computer hardware, network, internet, or database maintenance challenges. Institutional The proposed system will be utilized by multiple third party agencies and organizations. This will require coordination and collaboration across the region. Stakeholders that currently have automated scheduling systems may have to integrate into the proposed system via a “reginonal trip coordination” API or comparable solution. 1.3.3 Future Contingencies The current application has multiple third party dependencies. These third party dependencies are mission critical to the application. Failures or service stoppage severely impacts the applications capabilities.

SGT utilizes existing third party dependencies. These are currently availalble and published.

The dependencies include:

• Google Maps API – Utilized as mapping and geocoding engine for the application.
• Enhanced Services Program (ESP) Database Connector – Serves as data source for

HHS and demand response service providers.

• OpenTrip Planner API – Utilized to calculate fixed route trip itinerary.

Fixed Route Trip Planning API

The fixed route trip planning functionality utilizes Open Trip Planner (OTP). If OTP becomes unavailable or the service stops, SGT will fail. Google Maps would be a viable alternative for trip planning functionality. OTP is open source which would allow ARC to maintain the service themselves. This would require a minimal level of effort to maintain and manage.

Demand Response Options API

The current application incorporates demand response data from an in-house custom application – ESP. ESP is maintained and managed by the Aging Resources staff and utilize the system for information and referral. SGT is dependent on the transportation provider database. If not available, an alternative source would need to be developed, purchased, or integrated. This would be a major effort and not a good alternative. The risk of ESP becoming unavailable is minimized. ARC owns and manages this application directly. Due to the lack of major architectural and system design changes associated with the proposed solution, contingency risks are very minimal. 1.3.4 Document Organization This document completely describes the system at the architecture level, including subsystems and their services, hardware mapping, data management, access control, global software control structure, and boundary conditions. The document is organized into nine major sections. Each section provides detailed sub-sections relevant to the major section. Charts, tables, and graphics have been inserted to explain or clarify content.

SGT was designed to meet the transportation needs of human service transportation clients such as Veterans, military families, elderly, disabled, other transportation disadvantaged. SGT is a trip planning system designed to meet the transportation needs of human service clients including veterans, military families, elderly, disabled and other transportation disadvantaged groups. It: ▪ Provides unified trip planning for public, private and volunteer services; ▪ Works on computers, tablets, and smartphones; ▪ Is tailored to an individuals’ trip planning needs; and ▪ Empowers call center staff to deliver improved services. Veterans and their families are often in need of transportation services to enable them to attend medical appointments, receive physical therapy or mental health counseling, seek jobs or education, and access various veterans and related community services. Some veterans and family members have disabilities – mental, physical, or developmental – that exacerbate the challenge of obtaining these services. Numerous other populations experience similar challenges, including the elderly, transit-dependent populations, and other nonveterans with disabilities. SGT enables these target populations to quickly and easily identify the most appropriate options for making a particular trip, evaluating and identifying options that include fixed-route transit, demand- responsive transit (DRT), taxi and other private transportation services, paratransit, volunteer transportation service networks, carpools, and vanpools. 1-Click also provides call center or social service agency staff with a single, centralized source of this information to use on behalf of their clients. SGT tailors trip plan options to the needs, preferences, and schedules of each individual, based on factors such as Medicaid eligibility, veterans’ transportation eligibility (which depends on Veteran status and trip purpose), age, physical mobility limitations, and other preferences regarding tradeoffs of time, cost, and convenience. SGT also stores data that can be used to generate a variety of reports on system usage, mobility impacts, trips planned and made, and unmet transportation needs. 2.2.1 Proposed Solution - Statement of Need The current solution does not provide call center operational support nor does it provide the ability to coordinate other regional call centers and transportation resources. The solution must be extended to support these functional needs. The proposed system will dramatically improve call center operations, regional coordination, and, most importantly, the customer experience. Customers will be able to plan and reserve transportation online. Transportation providers will be able to connect to the one click system in real time to schedule the trip. Operations will have the ability to assign trips and to monitor performance in real time. Automated scheduling and routing will be available to optimize transportation resources. Automate dispatching tools will be available to the call center and to providers. This will create a single coordinated system for HST and demand response transportation. Transportation Network Companies (TNC) will also be integrated into the solution for a true multi-modal application. Transportation data analytics will be available at a regional level. Ultimately, the proposed system will execute the intended vision and requirements of a “one click” mobility management solution. 2.3 Stakeholder Roles/Responsibilities/Concerns System design can cross many different groups within an organization to ensure requirements are gathered and met for all stakeholders. As such, the roles and responsibilities section may be necessary to provide the team with clarification on who performs various roles. This section also serves as a list of points of contact for the team and stakeholders should issues and concerns arise which need to be addressed.

Regional Stakeholders

1. ARC Aging and Disability Resource Connection (ADRC)
2. ARC Transportation Access and Mobility Services Division

3. ARC Area Agency on Aging
4. Center for Visually Impaired (CVI)
5. City of Atlanta, Vehicles for Hire/Taxi Management
6. Cobb Community Transit (CCT)
7. DeKalb Office of Senior Affairs
8. Disability Link, the Center for Independent Living (CIL)
9. Goodwill Industries
10. Georgia Commute Options (GCO)
11. Georgia Department of Community Health (DCH)
12. Georgia Department of Human Services (DHS)
13. Georgia Department of Transportation (GDOT)
14. Georgia Governor’s Development Council (GDC), Rural and Human Services Transportation (RHST)
15. Georgia Transit Association (GTA)
16. Gwinnett County Senior Services
17. Lifespan Resources (volunteer driver program)
18. Metropolitan Atlanta Rapid Transit Authority (MARTA)
19. Ride Connection of Portland, Oregon
20. Atlanta United Way 211
21. Veterans Affairs (VA), Veterans Transportation Program (VTP) Additional support is provided by Kevin Chambers, IT Director of Ride Connection in Portland, OR.

Technical / Project Stakeholders

The following table provides the role and contact information for the key technical and project stakeholders associated with the system design. Table 1 : Project members contact information Name Role Email Mary Blumberg Executive Sponsor mblumberg@atlantaregional .com Cynthia Burke Project Manager [email protected] Leslie Caceda Application Owner [email protected] Ray Randolph IT Director [email protected] Tim Quinn Technical Lead [email protected] Carly Harper Business Consultant [email protected] 2.3.1 Roles SGT is designed to serve the needs of many different types of users, with features and functions appropriate for each one: ▪ Travelers are individuals in need of transportation services. Registered Travelers have a user account and travel profile, while anonymous Travelers do not have an account and can use the system without logging in. ▪ Buddies are friends, family members, or other caregivers who assist Travelers in creating trip plans and managing account settings. ▪ Agents are customer service representatives who assist Travelers in creating trip plans and managing account settings.

Project management responsibilities include delivering every project on time within budget and scope. Project managers should have a background in business skills, management, budgeting and analysis. Responsibilities:

• Coordinate internal resources and third parties/vendors for the flawless execution of projects
• Ensure that all projects are delivered on-time, within scope and within budget
• Developing project scopes and objectives, involving all relevant stakeholders and ensuring technical feasibility
• Ensure resource availability and allocation
• Develop a detailed project plan to track progress
• Use appropriate verification techniques to manage changes in project scope, schedule and costs
• Measure project performance using appropriate systems, tools and techniques
• Report and escalate to management as needed
• Manage the relationship with the client and all stakeholders
• Perform risk management to minimize project risks
• Establish and maintain relationships with third parties/vendors
• Create and maintain comprehensive project documentation

Lead Designer – User Interface

UI designer is responsible for creating intuitive user experiences. The ideal candidate should have an eye for clean and artful design, possess superior UI skills and be able to translate high-level requirements into interaction flows and artifacts, and transform them into beautiful, intuitive, and functional user interfaces. Responsibilities

• Collaborate with product management and engineering to define and implement innovative solutions for the product direction, visuals and experience
• Execute all visual design stages from concept to final hand-off to engineering
• Conceptualize original ideas that bring simplicity and user friendliness to complex design roadblocks
• Create wireframes, storyboards, user flows, process flows and site maps to effectively communicate interaction and design ideas
• Present and defend designs and key milestone deliverables to peers and executive level stakeholders
• Conduct user research and evaluate user feedback
• Establish and promote design guidelines, best practices and standards

Software Architect

Responsible for initial design and development of new software or extensive software revisions; products may be for use internally or for resale. Defines product requirements and creates high-level architectural specifications, ensuring feasibility, functionality, and integration with existing systems/platforms. Requires a bachelor's degree and may be expected to have an advanced degree in area of specialty and at least 7 years of experience in the field or in a related area.

• Demonstrates expertise in a variety of the field's concepts, practices, and procedures.

• Relies on extensive experience and judgment to plan and accomplish goals.
• Performs a variety of complicated tasks.
• May provide consultation on complex projects and is considered to be the top level contributor/specialist.
• May guide a team of developers through the project to completion. Typically reports to a head of a unit/department or top management.

Software Engineer

The software engineer builds high-quality, innovative and fully performing software in compliance with coding standards and technical design. Software engineer responsibilities will include development, writing code, and documenting functionality.

• Execute full lifecycle software development
• Write well designed, testable, efficient code
• Produce specifications and determine operational feasibility
• Integrate software components into a fully functional software system
• Develop software verification plans and quality assurance procedures
• Document and maintain software functionality
• Tailor and deploy software tools, processes and metrics
• Serve as a subject matter expert
• Comply with project plans and industry standards

Quality Assurance Lead

QA engineer responsibilities include designing and implementing tests, debugging and defining corrective actions. You will also review system requirements and track quality assurance metrics (e.g. defect densities and open defect counts.) Responsibilities

• Review requirements, specifications and technical design documents to provide timely and meaningful feedback
• Create detailed, comprehensive and well-structured test plans and test cases
• Estimate, prioritize, plan and coordinate testing activities
• Design, develop and execute automation scripts using open source tools
• Identify, record, document thoroughly and track bugs
• Perform thorough regression testing when bugs are resolved
• Develop and apply testing processes for new and existing products to meet client needs
• Liaise with internal teams (e.g. developers and product managers) to identify system requirements
• Monitor debugging process results
• Investigate the causes of non-conforming software and train users to implement solutions
• Track quality assurance metrics, like defect densities and open defect counts
• Stay up-to-date with new testing tools and test strategies

The major design considerations for the proposed extended features are related to system performance and scalability of the solution. Data center is hosted in AWS which provides a tremendous amount of flexibility in terms of scaling the performance. Processor speed, memory, peripherals, and stakeholder support will be factored in the design. 2.5 Goals and Guidelines The following goals must be addressed in the execution of the proposed solution.

Leverage Existing Architecture

The proposed solution must leverage the current architecture and system design used by current solution. This minimizes negative impacts on usability, user experience, and financials. The proposed solution will simply extend the current application to support additional features, functionality, and use cases.

Development Environment

The application development environment must remain consistent. This minimizes negative impacts to interoperability and quality. ARC does not wish to re-write or re-engineer the existing application unless absolutely necessary.

Ease of Use

The new features must be easy to use and provide a strong user experience. New features cannot impact existing functionality from a user perspective.

Extensibility

The proposed features must be extensible. Features can be enabled as needed or required by the users.

API Enabled

Regional coordination support is a key driver of the project. The application must be API centric and support an open and published API architecture.

RESTful Framework

The application and underlying architecture must be a REST framework. 2.6 Operational Environment ▪ Ruby on Rails Development ▪ Git Version Control ▪ Github Repository ▪ PostgreSQL Database ▪ Apache Web Server ▪ NGINX Server Functional goals of the proposed system includes:

• Extending functionality of the existing web application
• Improving application performance
• Sharing and coordinating data via a distributed model
• Completing the one-call one click deployment model

2.7 Development Methods & Contingencies The basics of a good architecture is to layer the application into multiple autocratic and autonomous applications that can be replaced individually and allow us to keep the application running while we are working on a specific layer. The communication between each layer should be a RESTful API call with JSON content. Scalability Ensure that the architecture can be scaled horizontally, across multiple servers and across multiple regions. That means that once your traffic goes up, you should be able to add and remove new servers as the solution requires. Availability The architecture should support a high availability environment. Infrastructure redundancy is required. This ensures the solution is available if multiple servers or an entire data center fail. The current availaibility of the solution per the hosting providers service level agreement is 99.999% availability. Security Solution architecture should expose only the minimal amount of code possible. Most of the back-end pieces should be hidden away. In addition to that, security of each system should be multi-layered. Extensibility Architecture must be able to swap out modules, change layers, and add pieces to the application without having to worry about the underlying data contracts in place. Separation of responsibility System should be modular enough that each piece of code has a set of responsibilities and not more. The back-end should not create front end code nor should the front-end code include business logic. RESTful Framework The reason for a RESTful API is plain and simple flexibility. Framework does not want to be tied or dependent on a specific programming language and architecture (Java or C#). Architecture needs to be able to replace each layer independently and even use different languages that might be better suited for a certain layer. 2.8 Architectural Strategies The Cloud trend is one of the most disruptive and challenging forces impacting customers’ applications and infrastructure, requiring new business models and new architecture decisions, which impact how organizations deploy, manage, maintain, and protect and manage their data. Amazon Web Services offers multiple options for provisioning IT infrastructure and the deployment of web-based applications. The deployment model varies from customer to customer. Below are the key strategies associated with this model.

Infrastructure On Demand

In a non-cloud environment: (i) infrastructure assets require manually configured, (ii) capacity requires manual tracking, (iii) capacity predictions are based on the guess of a theoretical maximum peak, and (iv) deployment can take weeks. Within the cloud, these building blocks that represent the Infrastructure are not only provisioned as required, following actual demand and allowing pay-as-you-go, but can also be programmed and addressed by code. This greatly enhances flexibility for both Production/Dev/Test environments as well as Disaster Recovery scenarios. Resources can be provisioned as temporary, disposable units, freeing users from the inflexibility and constraints of a fixed and finite IT infrastructure.