President's Perspective

More than Just a Purchase: Best Practices to Optimize and Contain your IT Environment

In this edition, we look at the components necessary for success in virtualizing to optimize your environment through an in-house, open systems utility. However, since the definition of terms is important in communicating on this topic, let's begin with the following, before I share the suggested recipe to cook by:

Open Systems: UNIX, Linux and Intel based environments

Utility: the in-house technology and defined processes that enable users to obtain the compute power they need, but in a manner that is in line with IT designed leveraged solution

Virtualizing your environment and building an in-house open systems (mid range) utility can relay quite significant benefits, including:

• Increased resource utilization

• Reduced computing and operating costs from consolidating workloads and sharing compute power in a scalable architecture

• Improved manageability

• Lowered costs of license material

To achieve these benefits, your organization must understand and master the technology in your data center; however, the technology remains only one aspect of successfully building this solution. In order to maximize your returns and ensure success, we must also address the following ten focus areas from the very beginning of the project:

Ensure Corporate Resolve

First, there must be a corporate resolve. This resolve must transcend all areas that will directly or indirectly impact the eventual building of the utility. The commitment to build the utility must be in place with IT, line of business, and at all key executive levels. If IT tries to build the utility only by itself, the effort is very likely to fail.

Create Centralized Ownership of IT Purchasing

Second, with respect to open systems, the given organization must pare back the ownership or authority set in buying server assets. Currently, many companies have a free-for-all set of processes for purchasing servers where line of business, procurement, and IT authorize the purchase with varying degrees of collaboration/communication. In some cases, servers are purchased solely by procurement, based on price point and delivery time line promises from the given vendor. In other cases, line of business purchases a server spec from a software provider without in-house IT consultation. In other cases, IT makes a purchase to meet an immediate need. Multiple buying authorities with different agendas or motivations lead to server proliferation and under-utilized assets.

Design involving both IT and Line of Business

Third, IT and line of business (LOB) must review and modify their design and decision making processes to support meeting the objectives of both teams. In order to reach the IT optimization vision, IT must be engaged early in the line of business review cycle to avoid the solution/server purchase from clashing with the utility architecture. Line of business has needs too. LOB knows how to review varying competitive software offerings. Whether it is a bank, retail, hotel, or manufacturing environment, line of business generally knows what it requires and how to evaluate the data capture and reporting capabilities of a host of competitive offerings. However, if IT is engaged too late in cycle to review and evaluate, they may not be able to provide counsel with respect to corporate standards and the preferred technology to support the utility. This leads to yet another "one-off" in many cases. Generally, IT involvement earlier in the cycle helps LOB work with ISVs to bring forward solutions that work with corporate standards, support the utility (are sized to a utility module or subset), while meeting the business functions and reporting requirements the project dictates.

Evaluate Internal Knowledge

Fourth, both architects and system administrators need to have the skills that support the building and maintaining of a utility. If architects understand advanced functions like fractional partitioning, virtual I/O, and other capabilities while the people that have to maintain/support the systems do not, the solution cannot become a reality. Reviewing the skills of both system administrators and architects is essential. After the review, develop a skill development plan for the various groups required to model, implement and support the optimization. These technology realm skills then need to be enhanced to match the unique technologies of the organization with respect to security, corporate standards, and best practices.

Set Corporate Standards and Processes

Fifth, make sure that the baseline corporate standards are defined and documented. Many organizations speak to corporate standards, but cannot provide a corresponding documentation set. This standard has to be living and evolving in step with technology developments and the ability to test validate and accept certain capabilities. It should define the acceptance criteria of how to try, prove and judge a solution to be worthwhile to leverage. Clear documentation with respect to corporate standards and processes can only enhance the trust between LOB and IT. Lack of such documentation makes LOB think IT is setting standards on-the-fly or inventing as they go down a given path.... not a cultural paradigm that fosters team play and confidence.

Continually Assess and Analyze Environment

Sixth, implement a tool that can extract granular and meaningful data with respect to server assets. There are several on the market that are not pervasive and after discovery will satisfy security conscious people. The better tools extract configuration details, including normal and peak utilization, and show the solution stack installed. Engage a competent consulting group or internal team with the time and focus to analyze the data. Obtain informational views from diverse areas of the business using the tool, so as to not get trapped into thinking a pattern is in place across diverse areas.

Begin with Proof of Concept

Seventh, from the tool output and analysis, develop a suggested proof of concept (POC). The POC should include the education ramp up of the required knowledge skills and the development of a baseline utility architecture, potentially consolidating work loads and showcasing the positive results. The results reporting should highlight the increased utilization, the improved manageability, the decreased compute power footprint, the reduced costs, and the additional savings accrued (licensed material, compute cost, etc.). Broadcasting the benefits is essential to developing further acceptance from all areas of the organization. Once the POC is demonstrably successful, steps can begin to take the initiative to the next level, building the utility out further. Virtualizing the environment is a must and involves educating the corporate culture on how to relate to a virtualized realm.

Educate the Users on the new Virtualization Technology

Eighth, develop a new way to relate (and price out) the virtualized capacity block to the given user. Users are predisposed to having their own serialized, physical server. Therefore, it is important to draw equivalence between the old physical server paradigm and the new virtualized solution. Specifically, correlating serialized capacity to virtualized capacity. Demystifying the new environment and way is imperative. The users need to trust in the new process. They need to see the proof that they are getting what they paid for...while also providing some upside if they do not need what they stated and other users can take over (and pay) for the unused capacity.

Prepare an Exception Process

Ninth, develop an exception process to deal with the required solutions that do not align to corporate standards and/or the utility architecture. The larger an organization is, the more exceptions there will be. An exception process model might simply be outsourcing. Another possibility is a dedicated center and/or group of people that solely manage to the exception based solutions. The exception process is not put in place to encourage exceptions but to have a workable solution in place to manage legitimate needs.

Plan for Future Growth

Finally, tenth, your organization needs to stay abreast of technology advances and build an architecture that can leverage new capabilities while preserving the original investment. Challenging the vendors to be creative in packaging and capacity on demand features is a good idea but should also include negotiations with respect to encouraging longer support time-spans for operating systems, serial number protection, and upgrade incentives. Demanding that key alliance partners assist in development of best practices around performance tuning, load balancing, systems management, and in getting the most out of your resource investments is something one should consider. Participation in user groups and in vendor round tables, in the quest to pick up best practices tips in building and managing your utility, will yield dividends. Through this all, you must also keep skills fresh through an ongoing commitment to education.

Those are my ten suggestion areas in virtualizing to optimize your environment through building an open systems utility. You need to start off on solid ground. Having the corporate resolve is key and containing the server acquisition authority is critical. From there, developing the processes and policies to support the building of a successful utility will be much easier and will yield huge dividends for the committed organization.

Why?

Before jumping into solutions, let's define the problem

That's why we believe we're on the cusp of a fundamental change in computing. In other words, trends in technology and the application of technology to the needs of business are coming together in a new era we call "e-business on demand." Sam Palmisano, CEO IBM

You need to have IT enable you to be a more adaptive enterprise. You need to use IT to compete successfully in a dynamic marketplace. Ann Livermore,  EVP HP

The only way out (of the IT challenges) is to go a different way. The way to the Dynamic Data Center. Fujitsu Siemens Web site

IT professionals are starting to recognize the value and importance of dynamic IT (a.k.a. utility computing, adaptive enterprise, on demand, etc.) in the data center. IDC Press Release

Everyone agrees - the last decade has seen too much proliferation that has limited IT's ability to respond quickly to business needs. Everyone agrees - we need to contain or reverse the proliferation so that IT can, once again, become more responsive. They don't all agree on what to call it, but as the quotes to the right demonstrate, all the major players in the industry are saying the same thing.

Never argue with a truism

Are all these sages right? Of course they are! Common sense says that a dynamic business with a dynamic, responsive IT function is a good thing. After all, who would argue the opposite - that a static, slow-to-react business is a good thing today - or ever has been?

We don't need to waste time looking at the essential truism in these ideas. Rather, we need to look at two practical aspects:

• Why is optimization and a utility approach so important right now?

• If it is such a good idea, why isn't everyone already there?

Why is it important right now? - The responsiveness paradox

In the last decade the majority of IT organizations have been creating a self-conflicting situation.

The Internet was a huge pressure for change in the mid 90s. The typical result was to install several servers (Web, DNS, firewall, email, ...). Progress was rapid, success was common and few people considered their existing IT investments to be a barrier to rapid deployment.

By the new century the pressure for change was feeding on itself. People were ready for the next level of Internet use with ecommerce, portals and sophisticated collaboration. But this was when we started to hear the first complaints that the "success" of the previous projects had created complexity that was making it harder to implement change. Server consolidation projects became popular and IT complexity was now on many people's radar as a barrier.

By 2006 we have seen another generation of changes that repeat the same trends:

• The pressure for change is enormous. Innovations as disparate as "Internet 2.0", Blogs, "software as a service" and powerful search techniques (like Google) are having a surprising effect that is requiring commercial and government enterprises to react to realities that not even the pundits foresaw. Compound applications employing Services Oriented Architecture (SOA) are being touted as a sea change that will transform the definition of the "IT department" and even blur the boundaries of the enterprise itself as we enter the era of the partnership-based extended enterprise.

• The recent history of IT is regularly quoted as an inhibitor to change. Many organizations are realizing that the panacea of "server consolidation" is too superficial and a deeper form of optimization and simplification is needed in several dimensions of IT.

With the power of hindsight we can now see that it was the rapid response to needs for change that resulted in the server sprawl and IT complexity that is now the inhibitor to providing a rapid response to needs for change! In other words, the approach we used to succeed contained the seeds of failure and was not sustainable for long. That's why containment is important right now and starting to move in a new strategic direction is vital.

Why isn't everybody already there? - Multiple dimensions to optimize

IT people are rather clever and ingenious. So, if optimization is as obvious and as powerful as the consultants claim, it should already be business-as-usual. The fact that it is still in the future indicates that it is unusually hard to implement. The chart to the right shows why.

To the left we see the obvious server proliferation. But that is just the tip of the iceberg. As you move in this diagram from left to right more layers are uncovered:

• Storage: Each server has storage associated with it - another layer that needs optimizing.

• Operating Systems: During this period many organizations "found themselves" with several new operating systems - both on their servers and on the desktop. Even attempts to avoid complexity - such as the use of "appliances" introduced embedded operating systems.

• Data base management systems and other middleware: Different DBMS were adopted because they were fashionable or because they were embedded in an application or appliance. Long before it became a mature part of the solution, other forms of early middleware proliferated as part of the problem.

• Backup and recovery: Different backup hardware and software often came with each server and were often considered a detail at the time of acquisition.

• Systems management: Each server came with "system-wide" management tools. But too often that meant different, incompatible systems management tools each of which was as wide as the system they came with.

• Development tools: Some new development languages and tools were a necessity for Web development. But there was great pressure to cram a wide range of new and different items into the development toolbox from Photoshop to Flash to AJAX.

Having arrived at the right edge of the chart - the IT skills - you will notice that the teams who have had to absorb all this change have not changed much. And there is much of the explanation. It's easy to order new, powerful hardware; it's easy to consolidate operational workloads. The real challenge is to consolidate and reorganize all the other layers - storage, database, middleware, backup and recovery, systems management and development tools. If that doesn't make your brain hurt, remember it has to be done by a set of skills that is already overstretched! So, that's why optimization progress has been slow in most organizations. 

Conclusions on "Why"

1. A responsive, integrated utility approach to providing IT in an organization is widely accepted as being of primary importance, in addition to being just plain common sense.

2. Although it was always desirable, its importance is becoming critical because we need to contain and then reverse the accumulated effects of rapid change over the last decade.

3. The transformation is not easy. There are multiple dimensions to be handled. The Catch 22 is that the people who need it most are so stretched managing the complexity that they don't have time to manage their way out of the complexity!

However, the goal is more than worthwhile. A responsive IT utility will provide a consistent and sustainable ability to respond to change. While this will not guarantee a competitive edge for the organization it is one of the prerequisites to creating success in our ever-faster changing world.

So, now it is time to look at solutions. What elements and approaches are more likely to lead to greater success in a shorter time? The next two articles provide some answers.

... on how these concepts apply to your needs

What?

The three-legged stool

One problem with breaking things down into detail is the danger of losing the essential unity of the subject. So, before we look at some details of what constitutes IT optimization, let's put a clear picture in our minds - a three-legged stool. This simplest of devices works perfectly if all three legs are in good shape - but is dangerously ineffective if any one leg is faulty or inadequate.

Leg 1: Infrastructure

For our purposes we define infrastructure to include all data center hardware, system software and middleware.

Infrastructure dominates most of the public discussion of IT optimization. This is what IT vendors can sell; so this is, naturally, what they want to talk about. That's why the majority of the reference materials and reports are about server consolidation and infrastructure simplification.

While infrastructure is only one of the legs, like the others it is vital to success. Here are some of the keys to success in building an infrastructure that supports a responsive, utility-like IT service:

• Architecture: Proliferation can be attained by accident, but the opposite requires a clear design. The design cannot be tied to products - they come and go too quickly. It must be firmly grounded in architectures that have long-term value. Then the products must be chosen and implemented to match the architecture.

• Standards: The architecture must be standards-based. In the bad-old-days of five years ago this was a difficult challenge. The good news is that, as we implement the second generation of Internet-age systems, there are many more mature standards that make this easier.

• Consolidation: This is often touted as the whole solution. While this is overstating the case, consolidation is, nevertheless, one of the prime elements in converting a complex, unresponsive infrastructure into one that can support rapid business change. While the concept doesn't need explaining, there are two aspects that often do not get enough attention:

  • Layers of consolidation: Much of the literature starts and ends with server consolidation; however, this is only the start. Even in the hardware area, consolidating storage, network, UPSs and cabling can be just as important. Rationalizing operating systems can have a big impact on both license costs and support productivity. Consolidating middleware, systems management tools and backup processes can have an impressive impact on costs and a massive impact on administrator productivity.

  • Resource relief: There are two resources that are in short supply for implementing any IT project: money and skilled people. Many people are surprised how much a consolidation project can contribute to the relief of these stretched resources. There can be truly staggering savings in every layer of a consolidation project - from hardware maintenance costs to software license costs to electrical power and cooling costs. As the chart illustrates, a consolidation project can also bring relief to the overstretched skills and free them up for their role in the utility that will respond to change on demand. Of course, the question remains, "How to find the skills and money to fund the optimization project that brings this relief?" We tackle this question in the next article.

• Living with the past: It's easy to talk about "legacy applications" as if they are something that happened years ago. But every new system instantly becomes part of the "legacy" that we have to maintain or replace. Tools or middleware that automate the modernization and integration of our legacy applications must be a vital part of our optimization architecture.

• Virtualization: It is difficult to exaggerate how powerful virtualization technology can be in optimization and modernization at every level. Combining servers; storage area networks; sharing middleware licenses; common backup and disaster recovery; modernizing applications; integrating systems management and administration. These and many other aspects benefit greatly from the almost magical capabilities of the best virtualization techniques. That's why we called this newsletter - virtualize to optimize.

Leg 2: Applications

It is not so easy to generalize about applications, so we won't spend much space on them here. However, it is worth making three observations:

• An IT utility that does not extend to and integrate the business applications is fatally flawed. So, this truly is one of the legs that, if weak, will cause the whole stool to fall.

• Some key application challenges involve integrating, modernizing and being able to extend/modify the function quickly. What we have defined here as infrastructure can perform much of the heavy lifting in these areas.

• The world of SOA and compound applications is already with us. Transforming our current monolithic applications to work in this world could be the home run in achieving responsiveness. "Transforming" could mean upgrading to a new SOA-based release or reengineering to conform to SOA standards or using middleware to dynamically intercede and perform the reengineering in real time. 

Leg 3: IT skills

This could be called the forgotten leg. For example, a recent well-respected consultant report on optimization devotes all of its 12 pages to infrastructure and applications; the only mention of IT skills is in tables of cost savings - as if we are not only going to optimize to eliminate servers but also to eliminate people!  The real objective should, of course, be to free up these valuable resources from maintenance tasks so they can spend their time as a vital agent of creative responsiveness in our responsive utility.

During the sprawl decade, IT resources became inefficiently stretched across systems that were too numerous and of too wide a variety. The optimization phase will correct these problems. But it will only do a good job if the IT skills leg is given its proper role in the whole process, including:

• The importance of IT skills should be paramount in developing the standards-based architecture. After all, if a superior standard is more costly to implement in hardware, you can be pretty sure that, given a couple of years, these costs will have been reduced to the trivial. However, if a particular approach is inexpensive in hardware but requires more time from highly skilled people, you can be pretty sure that this will prove to be ever more expensive in the future.

• Everyone starts their optimization projects with studies; they study server utilization, storage utilization, workload profiles. If included at all, people are often only represented as administration line items in the costs of operating the servers or systems. Surprisingly few study the IT skills inventory, job satisfaction and "utilization" of what they would freely admit is their most important resource. If you are evaluating an optimization methodology or partner, looking for how this aspect is handled can be telling.

Conclusions on "What?"

To be successful in containing proliferation and then building a responsive utility, an IT function must encompass:

• A responsive infrastructure. This can only be created from a standards-based architecture designed for efficiency, integration and the ability to grow and evolve. The power of virtualization will be needed extensively to tackle the issues of resource sharing, continual change and integrating the power of legacy applications.

• Responsive applications. Perhaps the ultimate measure of an application's responsiveness is its ability to work collaboratively with other services to form a compound application within an SOA framework.

• A responsive IT team. This is the only truly creative element in the "utility"; the only force for implementing truly new ideas or manufacturing major breakthroughs. First, we must free up this resource with simplification projects. Then, we must make sure that we design our utility to optimize this resource above all others. 

Sounds easy? If you answered "yes" you don't need to read the next article that provides some ideas on implementation.

... on designing your responsive IT utility

How?

A dose of reality

"Why do you keep tantalizing me with pictures of this perfect peaceful valley? I'm too busy fighting off the alligators to even drain this swamp - let alone climb over the mountain to the valley beyond!"

While this sentiment may be a little extreme, it represents the real dilemma faced by most IT functions:

• Budgets and IT resources are overstretched by current challenges.

• Transforming an IT function into a responsive utility takes money and the time of the IT team.

• In the goal of creating a responsive utility, how can we justify taking resources out of current projects? That involves the irony of being less responsive in order to become more responsive.

In this article we will try to provide some practical answers to this essential dilemma as well as some hints and tips. We will talk as if the reader is about to start their journey of containing proliferation and constructing a responsive IT utility; however, if you are already well on the way, there may still be some comparison points and ideas of value.

Reaching for help

The chart symbolizes the resource needs of this transformation.

Notice two things about the skills needed for transformation:

• If they are provided from the ever-shrinking pool of in-house resources available for development then we have to make the situation worse for a while in order to make it better. While this may be the heroic thing to do it should be avoided if possible.

• This transformation requires specialized tools and techniques - such as optimization study methodologies. For your organization these tools and skills are only needed once; therefore, investing in learning them will not provide long-term payback in other projects.

These factors clearly indicate reaching for specialized out-sourced help to assist with at least part of this transformation. There is a much higher chance of success - and more importantly, rapid success if you partner with people who have done this several times before and have the tools as well as experience. In addition, disruption of existing projects and commitments will be minimized.

Reducing the risk

There is more than one way to attain any goal; we strongly recommend the stair-step approach to on-demand utility transformation projects. Smaller steps can:

• Be completed quickly with reduced risk

• Be easier to accommodate in the budget planning process

• Prove the concept

• Establish early success

• Allow for course adjustments as the real benefits are better understood

• Allow time for establishing the longer-term changes such as the relationships between "customer" and IT that is appropriate for a responsive IT utility

Accelerating the returns and simplifying the process

It may appear that we are now going to contradict our stair-step recommendation. That's because we are - at least in one area. There are three reasons why we encourage you to think of prioritizing the acquisition of a powerful virtualization server.

Reason 1: Before it can be reversed, we need to contain the trend for proliferation. Having some spare capacity immediately deployable will remove any case for adding yet more servers. And if that spare capacity is on our chosen strategic, virtualization platform, the next urgent project will positively contribute to progress towards integration rather than the opposite.

Reason 2: As mentioned earlier, the cost savings from consolidating workloads can be spectacular. Therefore, it is possible to get early results that yield budget relief and help to fund later steps in the project.

Reason 3: The nature of hardware costs means that buying hardware capacity that is just sufficient for each stair step does not make sense. For example, instead of acquiring just enough capacity for the first step, you could probably acquire enough for the whole project with little extra cost. This would avoid the effort needed for incremental upgrades or additions and would give your team the flexibility to plan future steps knowing that the capacity is there whatever route they want to take.

For example, imagine an organization that owns several older UNIX servers. While they would like to consolidate them all immediately, the wisdom of the stair-step approach may indicate that it will take 18 months. But a cursory study could show the total capacity needed to consolidate all the workloads. They could then obtain a server with enough power for the whole project. With good financing, the total cost of that

server could be completely offset by eliminating the maintenance on only (say) two of the older servers as they mount the first stair step of their project. Power, space and administration savings would be added bonuses that would also kick in early in the project. The whole project may take 18 months, but the returns would start much faster.

Click on the picture to get a copy of the ITG report that explains the large savings available to better understand how your project could be self-funding.

A note from our sponsors

In TrendSetter we try to provide value by providing ideas on important issues - without pushing particular products or services. Up to this point, we hope you agree that this is true of this newsletter. However, this article is supposed to give practical advice on how to get started and what direction to take. In this context we break from our normal policy and give strong recommendations to two specific solutions.

UNIX servers: IBM has been proving superiority in two areas.

• System p has surged into the lead (see market share diagram).

• Their three decades of experience in virtualization has produced fruit in industry-leading virtualization engines on all their servers and in their storage solutions

Powerful, affordable servers that have superb virtualization capabilities are exactly what is needed to provide the server foundations for your simplification projects and for building your responsive utility.

Case study: The diagrams show an example of the remarkable options available. Here we see how four five-year old UNIX servers can be replaced by the latest System p technology. There is enough power to absorb the four workloads but better server utilization. The second diagram shows how dramatic can be the savings in maintenance; in this case (which is not unusual) the savings far outweigh the acquisition cost - thus providing immediate budget relief. Then you can add on savings in power, floor space, administration time and many other areas. But, most important, the new system provides the powerful virtualization features meaning that this is no mere cost-saving project; rather it is a major step towards a strategic simplification and optimization platform.

That's why we have no hesitation in asserting that System p should be the direction for implementing the UNIX platform in your infrastructure architecture.

Datatrend services: We have been helping our customers resolve the pressures of unbearable server proliferation for years. We would be proud to be your partner in building your responsive IT utility. The first step would be to show you the evidence that we have the tools, experience and skills to assist with all the elements described in these articles. Most importantly, we would like a chance to convince you that we can justify our membership of your team by accelerating the returns from your project.

... on designing your responsive utility

TechTip: Planning for Change in Your Infrastructure

By Debi Riedel, Director of Technology Resources, Datatrend Technologies

As the market acceptance of utility computing continues its growth, enterprises still face numerous obstacles in successfully adopting this new infrastructure. Enterprises may need to revisit the way they operate in order to successfully implement this change.

Key to the successful adoption of the utility will be the effectiveness of managing to the change.

Along with identifying potential areas for improvement, assessing the overall benefits, and selecting product or instituting process, planning the change is of equal importance.

When planning for change, first begin by considering the following items include:

• Communicate the Change

  • Make all parties affected by the change, aware of the change

  • Provide adequate time for affected parties to review and prepare for the change.

  • Always provide precise instructions and accurate detail related to the change.

• Justify the Change

• Define the risk associated with the change

  • What may be impacted

  • What is planned to minimize or eliminate the risk

• Include others, get the team involved

  • Ask for input

  • Giving adequate time to absorb and think about the change

  • Encourage questions

  • Build on their feedback

  • Always credit the contributions made by the team

• Always evaluate the effectiveness of the change, building on lessons learned.

This is not a complete list, but rather a condensed summary of items to be referenced when planning change in the infrastructure.

Contact us | Visit Datatrend website

All trademarks, registered trademarks and service marks are the property of their respective owners.
IBM, the IBM logo and other referenced IBM products and services are trademarks
or registered trademarks of the International Business Machines Corporation
in the United States, other countries, or both. All rights reserved.

UNIX is a registered trademark of The Open Group. Linux is a registered trademark of Linus Torvalds.

Brought to you by Datatrend Technologies Inc.

6815 Meadowridge Court, Alpharetta, GA 30005