SAP revolutionized enterprise software by making it more modular. Previously, enterprise software development had been a massive undertaking tackled by only the largest companies, resulting in software completely tailored to that specific business, and totally useless to any other organization. SAP’s breakthrough of splitting this software into tiers, with business-specific application modules sitting on top of standard databases, all feeding into the user-facing presentation layer, opened up the enterprise market to a whole host of other customers.
Because of their legacy systems and complicated business processes, many businesses running SAP – for core ERP, CRM, Business Intelligence amongst other uses – find themselves nevertheless supporting a variety of different platforms, systems, and servers in their implementation. This typically translates to a complicated development and testing cycle to ensure that all the pieces work well together and make business run smoothly.
Furthermore, the fact that a business’ SAP implementation is its central nervous system, and therefore absolutely mission critical, means that any integration and ongoing modifications must be tested, tested, and tested again. All this development and testing requires faithful physical copies of the eventual production environment. Research shows that for a given SAP environment in production, an organization typically has three to five additional environments of the same size on which to run development, testing, and Q&A. This means that a more or less typical 15-server production environment would require anywhere from 30 to 50 or more servers to support development and testing. Combined with mostly low-utilization rates in the five to 20 percent range, this army of servers mostly sits idle.
As any CIO talking to his CFO knows, these sort of complicated implementations are capital intensive. And as any SAP administrator knows, with the move to enterprise service-oriented architecture (enterprise SOA), the number of nodes in this networked application architecture is set to expand more. The proliferation of SAP xApps delivering a variety of services and communicating with the other SAP applications through an exchange infrastructure will make a given system more agile and responsive, but at the same time, even more complex than it already is. The standard model of dedicating a single physical resource to each service application simply cannot scale to support this new paradigm, short of breathtaking amounts of hardware spend. At the same time the goal of true enterprise SOA is too promising to ignore.
Virtualization erases application interaction
Server virtualization technology presents one solution to this dilemma. Virtualization is a technology that allows multiple, fully isolated virtual machines, each one composed of an operating system and application, to be hosted within a single physical server, with zero interaction between virtual machines within the same physical host. Virtualization’s ability to completely isolate virtual machines within a given physical server erases any chance of problematic application interaction. As far as an application running within its dedicated virtual machine is concerned, it’s the only application running on that OS. It’s also the only application using the virtualized CPU, memory, and other devices the virtualized OS “sees.” With the problem of application interaction solved, the main reason for dedicating a single physical server to each layer of the application disappears. There’s no longer any reason to let a server idle at a 10 percent utilization rate for fear of putting more than one application in it. Lazy servers can be revved up to merit their price tags.
Complicated test bed environments offer early wins
As mentioned above, under the traditional model of dedicated physical resources, multi-tier test and development environments represent the majority of the capital expense for a given SAP implementation. As such, those test and development environments present the biggest opportunity for server consolidation. With virtualization solutions, a single physical server can host up to 10 or more virtual machines, depending on usage intensity. Consider the prototypical testing and development server farm described above. Instead of 30 to 50 physical servers, each running at five to 20 percent utilization, and each requiring hardware upkeep, power, cooling, and rackspace, with a virtualization strategy in place, the same level of test and development support can be accommodated in as few as three to five physical machines running at 80 percent utilization or better.
Furthermore, beyond pure physical consolidation considerations, development and testing support processes tend to require quite a bit of churn within those test environments. Setting up multi-tier testing environments with physical hardware is a complicated, and time consuming process, with actual physical boxes needing software installed, networking, rollback, and so forth, all typically done by human hands. Virtualization presents a solution to this as well. Virtual machines can be configured from the administrator’s desk. Once configured, deploying a virtual machine into a physical server is done with a series of clicks.
This sort of streamlined deployment can be done again and again, letting development and testing support administrators focus on the valuable work of configuring machine images to their developer’s and QA engineer’s specifications, rather than spending time installing and uninstalling software and connecting and disconnecting physical boxes. Once deployed, those individual machines can then be configured into multi-tier environments, again, from the administrator’s desktop. Testing in an environment that is faithful to the ultimate production environment is a must have, but that doesn’t mean is has to be as costly and time consuming as physical configuration of test environments has typically been.
Automation extends virtualization
While a virtualization strategy for an SAP test and development infrastructure presents all these benefits, once a virtual infrastructure has been put in place, there is the opportunity for efficiency gains through its automation. The snapshotting functionality provided by virtualization solutions allows for the rapid redeployment of already-configured virtual machines. But in multi-tier test environments like those found in a typical SAP implementation, the deployment of a multi-tier environment of virtual machines can still mean a substantial time investment.
Even with the ability to configure virtual machines from a desktop client, provisioning a virtual machine running a web server, one running a CRM application, one running a business intelligence application, and a few running associated databases, before linking them all together into a working multi-tier, multi-system environment, is no small task. If the virtualized test lab is still managed and provisioned by a team of IT administrators, that team can be a potential bottleneck standing between internal customers and the virtual machines for their development and testing needs.
Lifecycle automation and automated deployment
Software lifecycle automation for the virtual test lab lets development and test support teams further exploit their investment in their virtual infrastructures. Rather than relying on development and test support IT teams to provisions and decommission their machines, developers and QA engineers can select pre-configured virtual machines from a searchable library of virtual machines, and automatically deploy those machines into a shared pool of physical server resources.
The same automated deployment is available for groups of machines, pre-configured and already networked, which is the typical environment for developing and testing SAP implementations. Developers and QA engineers can select multi-machine configurations from the shared library of SAP virtual machine images, and the software will automatically search out a host to deploy that multi-machine system into, deploy the virtual machines, start them up, and then allow the requester access to each machine through his personal workstation.
Many organizations implementing SAP take advantage of their global profile to use all 24 hours in a day to address business issues. Take for example, an organization that has development facilities in the Silicon Valley, Germany, and an outsourcing partner in Bangalore, India. With a virtualized test lab, accessed through software lifecycle automation software, those teams are able to access the same shared pool of development and test lab resources, and each of those teams can access each and every virtual machine and multi-tier system configuration, to support their efforts. This can mean that a particularly thorny development or testing problem can be passed along from team to team as the workday ends one place and begins another. As the day ends at one location, the team can take advantage of the ability to capture a “live” multi-machine configuration to the shared library, and the next team can start up that “live” configuration without missing a beat to continue testing or development.