Designing IT Workloads For Efficiency

Shifting a larger share of an IT project's budget to the concept and planning stages can help all the stakeholders proceed with a common framework. This includes designing from the infrastructure up to ensure that workloads are designed to meet specific business requirements.

Hani Elbeyali is a data center strategist for Dell. He has 18 years of IT experience and is the author of Business Demand Design methodology (B2D), which details how to align your business drivers with your IT strategy.

HANI ELBEYALI
Dell

IT has advanced rapidly over the last few decades, but often that innovation comes at a cost. Rapid development has led to a lack of industry-wide standards--at this point, there are not enough common reference architecture standards, terminologies, materials, blueprints or consistent codes. Yet, IT has become essential in doing business in all industries.

Proper Planning Is Necessary

A framework of agreed-upon plans is needed for success to be achieved in any multi-level effort. No one can imagine building complex design like a car or a skyscraper without all disciplines involved following blueprints and guidelines from inception to completion. If we compare IT infrastructure to a complex structure like skyscraper, a skyscraper built in the manner IT is built would be tilted, use only 50 percent of the floors and likely to crash to the ground when something goes wrong. This doesn’t usually happen to skyscrapers because real estate developers work with architects, engineers, construction managers and other trades who spend a substantial amount of time planning the project and all involved “speak” the same language.

Budget Allocation over the Lifecycle

Just as in the skyscraper example, spending on up-front planning is important. Figure 1.0 shows IT budget allocation and efforts are divided in three groups: Concept, Design and Plan, and Post-Deployment. Each of these three groups represents the amount of IT budget allocated. As you can see, little of the budget is spent on project concept, a bit more on design and plan, and most of the IT budget is spent on operation. The reason most of the budget is spent on operation is that not enough time and money are spent “investing” in the plan and design phase. This approach has created a large and complex IT operation that is costly to maintain and operate.

I find that maintaining IT requires about 75 percent of the IT budget and mindshare, therefore it requires most of the team’s attention. Yet there is a different method that works. If IT strategists start to shift a bit of the budget allocation to design and planning (as shown in in Figure 1.0) the reward would be huge saving in Operating Expenses (OpEx) for the overall IT budget.

Figure 1.0

Figure 2.0

A Business Value Approach: Business Demand Workload Design

Typically demand drives supply, but I find that in the IT market, supply is driving demand. I call this “supply-driven IT,” which means the suppliers create solution propositions that only address technical concerns, but they don’t really address business problems. Therefore, the solutions don’t really contribute to the business value and bottom-line profit.

Some examples of this include consolidation, outsourcing, unified fabric and virtualization. These types of “bottom-up” approaches are neither associated with discreet business opportunities nor do they present business value creation by themselves. They are presented to the business primarily as ways to improve IT OpEx, and inherently not to drive business. What is evident is these solutions continue to fail because:

1) There is little business value created in technical bottom-up approaches, and
2) CapEx impacts on OpEx dilute the ROI in the first two years.

In my opinion, the vendor’s approach “build it and they will come” is not the best way to create business value. What is needed is transforming the IT from “Supporting Function” to “Value Creating Function” for the business. This can be done by using business demand workload design. Instead of designing from the infrastructure up, design should be:

1) Aligned with business demand.
2) Workload profile based on top-down and bottom-up.

I will cover aligning with business demand in future articles -- for the rest of this post, I will focus on workload design, which has multiple benefits.

The advantages of workload designs include:

Reducing data center infrastructure waste by half, while increasing production volume by three times

Decreasing complexity and risk

Enhancing service levels and reducing IT costs

Monitoring and metering for each line of business independently

Delivering IT at the speed of business thus driving repeatable impact and scalability

To design workloads, here are the chronological steps you would take to work through the process:

a) Start by capturing the business goals and objectives, pain points and constraints through business workshops and a serious of meetings.
b) Translate from business demands to IT supply.
c) Create the workloads based on the business demand.
d) Align the applications with the business values.

Defining Workloads

There is little value of a highly optimized infrastructure without a plan for the applications because the infrastructure exists to serve the applications, which services the Line of Business. Workloads can be represented by single application, multiple applications, or single application can span more than a single workload. The point is: workloads are serving specific business needs and abstracted from the hardware they run on.

Applications rely on common design and architecture patterns, and for simplicity most applications can be grouped to run in one of these three workload categories; Stack (Fixed), Flex (Deformed), and Fluid (Liquid).

Next what is needed is create technical quality profile for each of these three workload types; by planning and design the infrastructure accordingly we can drive greater efficiency. The table below can be used to profile each workload type with specific technical qualities. Profiling workloads appropriately will drive the infrastructure hardware and software components. Example: Stack workload requires high CPU, and L2 depended, but Fluid workload requires medium CPU and L3. And so on...Click to enlarge.