 This is Dave Vellante of Wikibon.org, and I'd like to talk to you about one of the most pressing problems that has plagued IT since the dawn of computing. And that's backup. What's wrong with backup today? First, in and of itself, backup delivers no tangible business value. It's essentially insurance. Second, backup's expensive. For every dollar spent on primary storage, 50 to 60 cents is spent on backup and recovery. Third, backup is too complicated, and I'll talk more on this later. Fourth, data growth is outpacing backup advancements, and that's crushing backup windows. Fifth, backup is too often a one-size-fits-all capability where lower value applications get the same treatment as higher value apps, creating inefficiencies. And sixth, businesses are mandating that IT becomes more cloud-like. Today, organizations can provision servers in minutes and launch a new business initiative almost overnight, as the speed of business evolves so must backup. So why is it that backup is so complicated? Well, there are a lot of moving pieces to the backup system. Consider an Oracle environment today. You have a database and applications that are using that database. There are file shares that need to be backed up. There's a backup utility within the database, say Armand, for example. And there's a backup server hosting an application that orchestrates the backup and recovery flow for this environment. And of course, there's a target backup device and probably a replicated device off-site. Now, each of these elements has metadata locked inside. There are backup agents in the servers, and the format of the backup data is proprietary to the backup application. It's essentially locked in there. This is a hardened piece of cement. It's no wonder why backup teams don't want to change anything. So how must backup evolve? No longer is the idea of backing up a server the most viable approach. Rather, we're moving to a model where a VMware admin or a Microsoft Pro can access a catalog of services and construct a backup capability for a specific application. So instead of bolting on backup as an afterthought, backup should be intrinsic to the business process. Application heads or business users should have an option to consume data protection as a service, where the attributes of that service are tailor-able to the needs of the business. So how will backup as a service become a reality? Well, at Wikibon, we've identified four high-level enablers for this vision to be realized. The first is consistent space-efficient snapshots. This concept was a huge technological breakthrough for backup because it introduced a notion that sets of snapshots apply to specific applications. Second is this idea of a new orchestration layer, where today agents are tied up in the backup software. We see a separation of the agents, a new capability that has open APIs, an orchestration layer that can enable the management of backup from other systems. Now there's two key components of this layer, the metadata catalog, which is accessible from outside services, and a services catalog, which includes a policy engine that will allow practitioners to access and create services. Third is protecting data in native format, whereas today backup data is stored in a proprietary format. Finally, rich dashboards that you'd expect from a services-oriented approach, specifically a monitor that communicates the health of the backup system. This services-like model is designed to take an application view versus a server-by-server view. So here an application owner or a DBA or a VM admin sets the service level, the frequency of the snaps, the backup and recovery policy, the retention period, all that defined through the services catalog of the orchestration layer. So how should practitioners plan to implement a services-oriented backup approach? Well, first of all, we recommend starting with the organizational and business issues and sorting those out before jumping into the technology. Data protection should be a fundamental component of IT as a service, not an afterthought. Now technically, we don't believe this has to be a rip and replace. Because it's open, we see the orchestration layer as a component that can be slotted into the existing backup environment where you begin to migrate the existing pieces of the backup system into the orchestration layer. Pick an area of pain, for example, an application that maybe is under-protected and would cost too much to apply across the board. Move over time to new applications and your bespoke environment will become a services-oriented approach with consumable transparent services that the enterprise can access and utilize and reuse across the board. This is Dave Vellante at wikibond.org. Thanks for watching.