Converged Infrastructure: Prepare or Run for Cover?

converged infrastructure

Converged infrastructure (CI) describes the practice by storage, network, and server vendors to offer a joint, pretested, preintegrated platform. Server virtualization also plays heavily in such converged environments.

The result of CI is a highly tuned platform for optimal performance. Need more memory? Less storage? More I/O? Need to deliver 1,000+ virtual desktops? How about tuning for optimal performance of your database or Big Data applications? Joint, vendor-sanctioned SKUs, reference guidelines, reference architectures, and out-of-the-box settings offer various “knobs” you can turn to achieve such results from a CI solution. These are based on the vendors’ joint integration efforts that target key usage profiles.


IT teams have grown accustomed to doing much of the heavy lifting themselves when it comes to integration and testing of the various moving parts of their data center infrastructure. With CI, however, much of the legwork is done for you.

Many emerging cloud service solution providers now make heavy use of CI solution sets within their own infrastructures. CI technology is also being deployed as part of an enterprise’s own natural evolution to private cloud and hybrid cloud architectures. It is becoming an integral part of IT’s changing role to that of internal service provider to the business.

As part of this natural evolution to cloud-like service provider, the use of CI often appears at a pivotal mid-stage in the process. This is where the IT organization begins to focus more on automation and methods that further automate provisioning of resources. It’s also where IT moves from being reactive to more proactive. Here, the organization turns its focus away from specialized, siloed operations and the manual provisioning of disparate server, storage, or networking assets. Instead, it moves toward the automated provisioning of higher level functions (including the delivery of services from a unified platform).


Here’s an analogy I often use to explain CI: In contractor terms, you can think of CI as a solid building foundation. You haven’t necessarily designed all the rooms or walls yet, but CI gives you a stronger, more flexible foundation from which to layer. This solid foundation helps you more effectively build either single-family housing (such as an application-specific architecture for SAP or Oracle) or multi-unit housing (like data center services or a service catalog for various, emerging application needs).

Other CI benefits tend to include:

  • Faster time-to-market and greater agility.
  • Less overall work for IT projects—from procurement to design, implementation, testing, and ongoing support (support issues resolve more quickly through combined vendor effort).
  • Less risk of IT failure and less downtime.
  • Greater system efficiency, better resource utilization, and better application operations.

There are several examples of successful CI in practice. One involves a globally recognized higher education company offering both online and brick-and-mortar learning environments around the world. Important to IT was the need to handle aggressive development, testing, and rollout schedules for new educational applications. Also needed was a better handle on peaks in student digital workloads throughout the school quarter.

The organization chose to deploy a virtualized CI environment to achieve a more elastic, scalable, and affordable infrastructure. Using CI, the company was able to decommission many of its physical servers and has since experienced significant cost reductions in power and cooling. New application environments no longer require a six-week deployment and coordination with multiple teams. The new environments can now come online in under a day. Virtual workloads can now also be moved or shifted quickly to address current on-demand needs.

In another case, a software company wanted to fuel growth, yet reduce the time and cost to release new solutions. The owner opted to change his business model to a SaaS provider, but knew he’d need higher levels of service from the company’s own infrastructure. Using CI, he was able to bring a higher value SaaS product to market much faster and at a lower cost than originally anticipated.


IT organizations tend to implement CI in one of two ways:

  1. Bright flash of light.  Some organizations choose to make a wholesale infrastructure upgrade to CI (and a related new cloud delivery system) all at once. This might be associated with a specific application or new project initiative.
  2. Steady as she goes. Other IT organizations see the move to CI (and private cloud) more as a journey to be taken in phases, rather than a single destination. As business issues arise or technology refreshes occur, they may switch part of their infrastructure to a CI-enabled component. This might mean selecting a certain type of blade server, or a certain type of storage. Over time, they gain the pieces of a CI reference architecture to be turned on in full later when all the puzzle pieces fall into place.

In the short-term, CI implementation means using components from a reference architecture with best-of-breed companies. Organizations focus on what they can do today. In future, tighter integration and further convergence between components is likely.

For more medium-term deployments of CI, IT organizations might look to deploy either application-specific CI models (SAP-specific, for example) vs. more general-purpose CI architectures.

Just as with any other project, some legwork is still required, especially as it relates to the service levels needed to ensure proper security, availability, and performance. Specific design points in CI reference architectures can make it easier to support secure multitenancy or gold-level availability, but they still require IT due diligence. A converged infrastructure with 10 clients offers multitenancy (i.e., no comingling between Client A and Client B data). If you have a mission-critical application that needs “gold” vs. “bronze” level resources, CI reference architectures also let you automate service levels to ensure the right amount of bandwidth and storage.


Understanding the difference between the main CI models and its varied language is important. Analysts and vendors have called CI everything from virtual data centers (VDCs) to fabric-based infrastructure (FBI) and unified computing (UC). More recently, IDC referred to the CI market as “integrated infrastructure and platforms,”1 while Gartner referred to it as “integrated systems.”2 Learning such nuances is essential to CI success. Yet, success also hinges upon a new way of thinking:

  • Changing how IT teams work together. Many IT teams are organized as separate application teams, server teams, network teams, and storage teams. To be successful with CI may require a refocus and/or restructuring of the teams to reflect the new, converged infrastructure. Service levels for applications must be achieved as a whole, with all unified resources, not with disparate resources and teams.
  • Changing procurement. CI solutions require a different way of approaching traditional purchasing or procurement. The old way typically focuses on buying separate IT components for the cheapest possible vendor cost, then relying on the internal IT team to make them all work together. With CI, education is needed to convince procurement how (and why) to buy converged solutions from a qualified provider and understand it is a complete solution vs. an independent set of vendor products that can be bid out as parts.
  • Changing expertise. The nuances and benefits of different CI models and different CI vendor offerings can’t always be discerned by traditional IT integrators whose expertise might lie more on the application or server side. Where needed, organizations should seek help from experts or integrators with a strong background in unified platforms and converged infrastructures. You may also need to invest in cross-training individuals within your own IT organization.

In the long-term, it’s important to see CI as a steppingstone to a future state: that of delivering IT resources as a service. Sure, CI can make you faster and give you less downtime, but it may not dramatically change users’ interactions to IT services.

Even though your IT organization may not be ready quite yet to define or automate core services for users, it should look to the future and consider how CI architectures and emerging tools can help better support delivering IT as a service (ITaaS) to constituents. This may involve rewriting applications to better align with business goals. It will also involve adjusting the people, processes, and technologies to support your new CI-fueled, service-oriented mind-set.


1. Source: IDC Worldwide Integrated Infrastructure and Platforms Tracker, Oct. 2, 2013, available at:
2. Source: “Market Share Analysis: Data Center Hardware Integrated Systems, 2Q13,” by Adrian O’Connell, Gartner, Inc., Document #G00257711, Dec. 12, 2013,

About Kent Christensen 1 Article
Kent Christensen is the practice director for cloud and virtual data centers at Datalink.