Taming the business and cultural challenges of a shared application infrastructure using WebSphere Virtual Enterprise

An organization's move to shared resources can result in higher levels of value, service, and cost savings. It's also a cultural shift that aligns business objectives more directly with IT operations and reduces the operational autonomy of individual development and deployment teams. This article looks at the business and operational impact of a shared infrastructure, and ways to approach the hurdles on the way to achieving this environment. This content is part of the IBM WebSphere Developer Technical Journal.


Nitin Gaur (ngaur@us.ibm.com), WebSphere IT Specialist, IBM

Nitin Gaur has been with IBM for 9 years and is currently a WebSphere IT Specialist with IBM TechWorks. Nitin was previously on the WebSphere OEM and AIX support teams. He is an IBM Certified Consulting IT Specialist and Advanced WebSphere Administrator as well as an AIX Certified Advanced Technical Expert. Nitin is an active member of the Austin Technical Vitality Council, an IBM Academy affiliate, and has presented papers on a wide range of subjects, including software architecture and improving management processes, at various conferences.

18 June 2008


Previous articles have explored the business value of IBM® WebSphere® Extended Deployment, along with the various autonomic and grid components of which they are comprised. The goal of those articles was to demystify WebSphere Extended Deployment and surface real world deployment considerations involving a virtualized middleware environment. This article, in contrast, looks at the business impact of adopting WebSphere Virtual Enterprise (formerly a component of WebSphere Extended Deployment) as a platform for a shared services environment, and also at the changes that might be induced due to the implementation of a virtualized and shared deployment environment for enterprise applications.

Because WebSphere Virtual Enterprise targets application infrastructure services, it is bound to impact not only the IT custodial entities, but also the line of business (LOB) entities, who are typically the internal customers of an IT infrastructure service. Hence, effective change management becomes an important and vital activity when introducing WebSphere Virtual Enterprise (hereafter referred to as Virtual Enterprise) to an environment.

While adding value to the IT infrastructure in terms of costs savings (with server consolidation), Virtual Enterprise features such as application editioning, policy-based request flow, and chargeback, also surface the challenges around LOB control of their deployment environments. For example, changed chargeback models might force LOB units to rethink their deployment priorities to have the least impact to business units. Moving to a shared infrastructure means subscribing to a shared services model with shared resources, enabling new processes around application development, deployment, and management in a new environment. Of course, while the enterprise as a whole might significantly benefit from the economies of scale achieved with this virtualized resource pool, the impact to individual LOBs should not be ignored.

This article also discusses a business value analysis of Virtual Enterprise, which looks at the tangible and intangible value of adopting the product. It is critical to understand your existing cost structure to be able to create an accurate estimate of the cost benefit analysis, which would list the cost of implementation and compare it against the (tangible and intangible) benefits derived from a shared infrastructure. Two commonly used valuation concepts with regard to a business value analysis, return on investment (ROI) and total cost of ownership (TCO), are also discussed a bit to demonstrate the importance of alignment and linkages between business processes and IT processes, and also to explore important business considerations when adopting Virtual Enterprise as a shared infrastructure service.

Business impact of a shared infrastructure

The business impact of a shared infrastructure represents a significant shift in the mindset of an LOB manager. This is primarily because, while the cost benefits of moving to a shared infrastructure are compelling, the move to a shared, utility-based infrastructure requires changes in current control processes. For instance, the process and time requirement to promote an application from staging to production might require additional planning and approval than it currently does in order to fit into the context of a shared infrastructure. Placing this in the Virtual Enterprise context, application owners would now be required to decide on application priority and boundary for growth, along with the cost implications related to these decisions. Such decisions might force application teams to work closer with LOB analysts to determine the business policies around the cost structure, as defined by the infrastructure management. Also, due to new chargeback features enabled by Virtual Enterprise, poorly written applications will no longer be subsidized, and will incur more run time costs due to higher resource consumption. Much like your utility bills, the chargeback model will force LOB and application developers to continually assess their applications’ performance in order to incur less cost.

Perhaps this foreshadows a point of contention between business unit analysts and application developers. In the long run, the economies of scale enabled by Virtual Enterprise might force application development teams to adopt standard development practices for building better performing applications -- but perhaps this is more of a philosophical discussion. Nevertheless, like all changes, those introduced by Virtual Enterprise as a shared infrastructure will face its share of resistance, and effective procedural change management by involving all stakeholders might be the first step in Virtual Enterprise adoption.

Let’s look at the business impact of some of Virtual Enterprise features. Figure 1 maps various Virtual Enterprise features and their impact and visibility to an organization. A mapping such as this can be helpful when studying the impact of Virtual Enterprise features to be adopted, and the related effort required for change management. Each of the features in this diagram is explained below.

Figure 1. Impact and visibility of Virtual Enterprise features
Figure 1. Impact and visibility of Virtual Enterprise features

Application and patch management

This Virtual Enterprise feature enables easy management of several editions of same application deployed in the enterprise infrastructure, and easy management of WebSphere product fix packs or interim patches. While the application editioning feature might impact the LOB application development teams, the centralized installation manager (CIM, for patch management) will impact the IT custodial or infrastructure teams. Both of these nifty features, although very handy, forces the rethinking of existing product and application modification processes and, in some extreme cases, could render them impractical or unusable due to the new lines of control between organizational units.

Let’s take application editioning, for example, which enables multiple versions of any application to run simultaneously. This features is useful when validating a newer version of an application prior to rolling it into production. The advantages of this feature include significant time and cost savings because it enables early error detection during validation and rollout while maintaining continuous application availability. Successful adoption of application editioning would include changes to your existing version control systems to accommodate this Virtual Enterprise feature, possibly integrating with existing tooling support for application deployment. Other changes might include education on the new deployment processes to development and infrastructure teams, and defining new lines of control, accountability, and governance around application management. Technically, edition management is a relatively simple process, but the accountability and process changes around governance could also require upper management support.

CIM might have less of a business impact than application editioning since the use of this feature is localized to WebSphere administrators or WebSphere infrastructure teams. Advantages of CIM include patch or fix pack environment upgrades with no interruption to application availability, and easy fix pack management. Adoption of CIM might also include a review of existing processes, lines of control, and additional education.


The idea of chargeback might be one of the most alien changes to those considering a shared services infrastructure. Chargeback represents a cultural change because not only does a shared environment need a mechanism for actually sharing the cost, but also to calculate and charge the cost based on consumption. The challenge of chargeback revolves around devising an equitable chargeback model that is agreeable to all participating LOBs. Besides the control and cultural hurdles around chargeback, additional chargeback modeling tooling, such as IBM Tivoli® Usage and Accounting Manager (ITUAM), and expertise could be required for ongoing billing and management. While Virtual Enterprise will generate a raw (CSV) file with chargeback information by application (and resources consumed by them), the file will have to be imported into a tool (or at least a spreadsheet) to tabulate the data. Chargeback models are discussed later.

Unified administrative model

Virtual Enterprise can also manage heterogeneous application server environments. This means that Virtual Enterprise can not only manage various versions of WebSphere Application Server, but other middleware servers as well, such as a JBoss, Apache Tomcat, Glassfish, BEA WebLogic, and more. While the administration of WebSphere Application Sever is, of course, seamless (since Virtual Enterprise is build on top of WebSphere Application Server Network Deployment), other application servers are supported at varying levels. PHP servers and WebSphere Application Server Community Edition are treated the same as WebSphere Application Server, with full (lifecycle) support. Other middleware servers are provided with assisted (lifecycle) support, which means that Virtual Enterprise can manage (start, stop, and so on) and cluster these servers, but other administrative tasks, such as tuning and application installation, must be performed natively on those systems. The On Demand Router component can route any request to any HTTP endpoint. The flexibility offered by the unified administrative model’s ability to manage all types of middleware servers that might exist in an enterprise is tremendous, including one view of the entire environment, easing inventory challenges and overall manageability.

Of course, this feature has its own adoption challenges as well around line of control. While the technical capability exists in Virtual Enterprise to manage and cluster these environments, it is culturally difficult to break the existing native clustering mechanism and relinquish control to a Virtual Enterprise administrator. There is also the consideration of maintenance accountability of heterogeneous middleware environments. Administrative teams would still have to perform maintenance for application deployment, patch management and troubleshooting of non-WebSphere middleware server environments, so some organizations might not initially see a lot of value in implementing this feature, despite the advantages that unified administration has to offer. The key to successful transition in these cases is to standardize the application deployment process across all platforms, and perhaps use Virtual Enterprise as an administrative entity.

Table 1. Support for heterogeneous middleware servers
Level of lifecycle managementSupported servers
  • Create/remove server instances
  • Manage server configuration
  • Complete operational control
  • Application deployment and administration
  • Server health and performance monitoring and visualization
  • WebSphere Application Server
  • WebSphere Application Server Community Edition
  • PHP
  • Specific templates for creating representations of existing servers and applications
  • Operational control of servers
  • Administrative utilities to manage configuration and run time
  • Server health and performance monitoring and visualization
  • JBoss
  • Apache
  • Tomcat
  • BEA WebLogic
  • Geronimo
  • Generic templates to manually define servers
  • Operational command templates
  • Control server operations and some monitoring of health and performance
  • .NET
  • NetWeaver
  • Glassfish
  • Custom application servers

Operational policies management

Virtual Enterprise is an autonomic system, primarily driven by policies, and there are two major types of policies that govern the behavior of a Virtual Enterprise environment:

  • Service policies, or service level agreements (SLA)
  • Health policies, to manage the health of the run time environment.

While service policies and chosen application importance levels might directly impact LOBs, health policies are primarily for proactively managing the continuous availability of applications. It is vital to understand the underlying drivers behind these policies, and to communicate them through education to all users of the shared infrastructure.

The choice of service policies and application prioritization resides with the LOBs deploying the applications, but the cost implications of these choices will be reflected in the chargeback model; this will need to be communicated to the participating LOBs. It makes sense that applications with highest priorities and the most ambitious SLAs will require priority attention by infrastructure resources (application server instances, memory, CPU, and so on), resulting in higher costs. Over time, LOBs should continually evaluate their development practices, service policies, and priority levels to keep costs low and continue to adjust until they are optimal to their business objectives. Applications with unrealistic service policies could see high resource consumption while not meeting their SLAs, which can be corrected by adhering to application benchmark testing and deriving more realistic application response times. Changes due to a business policy driven environment can be controlled with continual education, involvement of all participating LOBs, and by creating a body of knowledge around best practices to keep costs low in a Virtual Enterprise environment.

Figure 2. Categorizing application priority based on organizational relevance
Figure 2. Categorizing application priority based on organizational relevance

Economic value and changing mindsets

While value can be perceived differently in different business units of the same organization, the value drivers almost always revolve around cost and derived benefits of the investments. In other words, the main goals of any value system are to maximize the return on investment and increased profitability, but the priorities and cost focus may differ. For example, even though an application development team sees value in adopting a specific software solution, the infrastructure team might not see the same value, perhaps due to the high cost of support as a result of maintaining the software. Such situations can be common and can sometimes impede the adoption of new technology.

This section looks at the cause of such divides and looks at an approach to understanding the underlying value systems that govern and drive LOB decision making. Evaluating a value system requires you to first comprehend the constraints of a business unit, because it is these constraints that define the value of a resource or technology.

Value systems

The value system in the context of a shared infrastructure is a set of values and measurements used for the purpose of defining productivity that is related to efficiency and effectiveness. The common units of measurement used to derive value are usually quality and cost. Therefore, if a business unit can deliver better quality of service in shorter time at the same or lower cost, then the value of the service delivered is said to have increased. Efficiency, in this discussion, would imply employing efficient use of available resources to drive the costs down. The cost structure would include the cost of hardware, software, support, and consulting resources, plus the opportunity costs due to availability and downtime. Effectiveness, in this context, would mean making the right decisions and doing the right things to create the most value for the organization as a whole.

The term “value system” is used here due to the federated nature of operations management in any IT infrastructure. The value system encompasses the combined value of individual LOBs and the values of the organization as a whole. This is an important aspect to consider, as many strategic decisions, which are long term in nature, ultimately translate into tactical and operational decisions. For example, the overall strategic direction of an organization might include the possibility of data center consolidation, with a higher level goal of saving energy, real estate, hardware, and software costs. This initiative would translate into the review and implementation of data center consolidation technologies, such as hardware virtualization, energy efficient systems, and software and server level consolidation technologies, like Virtual Enterprise or WebSphere Extended Deployment. When such initiatives become a strategic mandate, the LOBs are then also required to participate at a tactical level to comply with such a mandate. This shift, though it may seem like imposed compliance, is targeted to achieve efficiencies through maximizing the use of hardware and software assets, driven by operational policies.

The main concern of moving to a shared environment is cost implication, as the LOBs must be convinced that their business unit will achieve significant costs savings in exchange for giving up control of their dedicated infrastructure, and that the cost basis is not subsidized for other business units. While tools such as chargeback provide mechanisms for dividing the costs of shared services, there are several other cultural and operational hurdles that can make the transition to shared services a challenge.

Value analysis

The purpose of a value analysis is to simplify processes to measure the efficiency of the infrastructure, aiming to achieve better quality of service at a lower cost. The main goal is to lower costs, but not at the expense of downgrading any operational and functional requirements. Now, in many cases, these operational and functional requirements are defined by the customers (or the LOBs) and maintained by the IT custodial or the IT infrastructure teams. The business value analysis of implementing Virtual Enterprise or WebSphere Extended Deployment begins with identifying and curtailing overlapping or unnecessary costs.

Figure 3. Virtual Enterprise five-step business value analysis to quantify the value Total Cost of Ownership
Figure 3. Virtual Enterprise five-step business value analysis to quantify the value Total Cost of Ownership

The value analysis of adopting Virtual Enterprise considers the total cost of ownership and calculates the annual cost saving by factoring in the benefits of a consolidated environment that could include reduced hardware and software requirements, reduced manageability, and efficient use of assets. These value analysis models not only address the basic economic value of cost reduction and profitability at the infrastructure level, but also bring forth other intangible value themes, such as improved availability and easier environment management. These values are often not directly measurable to a financial statement, but they are significant enough to be considered functional requirements.

The economic value, on the other hand, is derived from the infrastructural costs to support and maintain the environment for business support against the financial metric (which includes revenue, ROI, profitability, percentage of total business costs, service level to customers, and regulatory compliance requirements). In some cases, LOBs embrace tremendous value features such as SLA and continuous availability (even though these features do not directly impact the revenue or costs savings) when the cost of non-compliance is far greater than the generic economic value measurements. Compliance to standards such as HIPPA or SOX, which are important for regulatory compliance, are sample cases.

Table 2. Sample business value analysis comparing tangible and intangible features of Virtual Enterprise
Tangible benefitsIntangible value-add
Dynamic operations enable multiple applications to share a common pool of servers, maximizing utilization of server resources
  • Reduces number of servers
  • Provides higher utilization of servers
  • Reduces CPU-based licensing costs (for hardware, software, and so on)
Extended manageability reduces administration costs
  • Fewer servers = less administration support
  • Visualization console provides consolidated view of all applications, potentially reducing duplicate administrative support and simplifying many administrative tasks
  • Self-healing features can eliminate on-call support
Reduces business costs due to reliability of infrastructure
  • Business costs directly tied to application downtime
  • Contractual penalties for failure to meet SLA
  • Improved availability
Reduce the risk of unexpected change results
  • Use WebSphere Extended Deployment coexistence facilities to run two versions of an application side by side for pilot programs
  • Flexible routing enables the administrator to make changes without exposing them to the end user
Provide consistent response time as customer volume increases
  • Leverage virtualized, goal-directed, autonomic infrastructure to maximize resource usage, limit server proliferation, and administrative costs
Make application changes outside the normal maintenance window
  • Use WebSphere Extended Deployment facilities to drain traffic from application servers and roll out code changes without interruption

While Virtual Enterprise business value analysis is the first step in identifying and quantifying the costs savings from the benefits enabled by Virtual Enterprise and shared services, IT custodial and business leaders must ensure that Virtual Enterprise fits the overall strategic intent of both the organizational and LOB objectives, important for ensuring acceptance from all participating business units, as well as consider other applicable cultural challenges.

Devising equitable chargeback models

In many organizations, both large and small, the methodologies used in devising a chargeback model are overly simplistic and dated. New technologies and application development patterns either render these models inadequate for today or not reflective of how resources are actually used by applications or business units. Devising an equitable chargeback model can be the most complex of all challenges involved in adopting Virtual Enterprise. Chargeback models are complex for many reasons, one of which is the ability to arrive at a cost model that is agreeable to all business units, another being the complications of formulating the fixed and variable cost distribution of the underlying shared infrastructure. In some cases, this could even lead to obtaining a business analyst just for this task. Let’s look at some chargeback considerations for ways to simplify the chargeback model.

Figure 4. Sample resource usage by three applications to determine the operating costs
Figure 4. Sample resource usage by three applications to determine the operating costs

Chargeback models

First, what exactly does "chargeback" mean? In consolidated environments, the IT custodial service employs a cost recovery mechanism that institutes a fee-for-service type of model. Chargeback enables IT to position their operations as value add services and uses the cost recovery mechanism to provide varying degrees of service levels at differentiating costs. To devise an effective chargeback model it is imperative that the IT organization have a complete understanding of their own cost structure, including a cost breakdown by components used as resources, a utility-like model to justify the billing costs associated with resource use. When it comes to employing chargeback models, there is no silver bullet that will address all the perceptions and user expectations from an IT services commodity model. There are several models prescribed and practiced in the industry today, and each will be a different cultural and operational fit for an organization. A few chargeback models are described below, but a hybrid model combining select features of more than one model is also an option.

  • Standard subscription model

    The simplest of all models, this one involves dividing up the total operating costs of the IT organization by the total number of applications hosted by the environment. This type of cost recovery is simple to calculate, and due to the appeal of its simplicity, finds its way into many organizations. The year to year increase in IT costs due to growth and expansion is simply added to the subscribers’ costs. While this is a simple chargeback model, it is fundamentally flawed, as it promotes subsidy and unequal allocation of resources (with this model, a poorly performing application is subsidized by other applications) and de-emphasizes resource consumption and application footprints.

  • Pay per use model

    This model is targeted for environments with LOBs of various sizes and, unlike the standard subscription model, emphasizes charging based on an application’s actual consumption of resources and SLA. For example, an LOB might pay more for shared services simply because its application requires a larger footprint, or because they desire a higher degree of preference, more dedicated resources, or a more demanding service policy. This model can be complicated in its approach, simply due to the framework around resource usage and monitoring, but it ensures fair and equitable cost recovery. The downside is that it might take longer to arrive at agreeable metrics and cost models associated with resource consumption.

  • Premium pricing model

    The premium pricing model focuses on class of service and guaranteed availability of resources for business applications. As the name suggests, LOBs will incur a premium for preferential treatment of application requests and priority in resource allocation during times of contention to fully meet the service goals. This could also include a dedicated set of hardware nodes to host applications, so depending on the degree of isolation and separation from the shared services model, the cost can increase. Such models are often preferred by LOBs with mission critical and high revenue impact applications. This model will typically coexist with other baseline chargeback models, since not all applications or LOBs in an organization will require premium services.

  • Sample hybrid model

    The hybrid model combines the advantages of multiple chargeback models to best suit an organization. For instance, a hybrid model could have a flat entry fee per application to cover the cost of the base infrastructure, and then pay for actual resources consumed. The flat fee can be characterized as a fixed expense to be hosted, and the additional costs for resource consumption can be linked to variable cost. This example combines the standard subscription model and the pay per use model into a utility-like billing service. Since there is no single chargeback model that will fit all environments, it is common to see several model types combined.

While there are advantages of using one chargeback model for an entire organization, there might also be value in introducing a catalog of chargeback models and offer a choice to LOBs. This type of flexibility enables an LOB to select the most suitable chargeback model for their needs, and avoids the challenge of getting all business units to agree on one model. However, multiple chargeback models only work if all models are comparable in fairness and value; all things being equal, the same application should have same operating cost under every model, but differing costs when varying volume, Quality of Service, chosen service policy, and so on.

Simplifying chargeback

Chargeback is an important tool to align IT services with business objectives, bringing together IT and business operations to understand the value created by shared environment services. The ultimate goal of any chargeback model in a shared environment is to provide the business with resilient and robust value add IT services at a competitive cost. These cost advantages are enabled by efficient use of hardware and software resources, and the resiliency comes from harnessing the computing power of a virtualized grid-like IT infrastructure, enabled by Virtual Enterprise. Chargeback models, by their very nature, can be complex and can require education for both business and financial communities alike.

Simplifying chargeback is vital to adoption and acceptance of a shared service infrastructure. The first step to simplification, then, is education on the purpose and intention of adopting Virtual Enterprise. Education can also be used to gather requests for comments on appropriate chargeback models to get a baseline of the general mindset around chargeback.

The second step should include obtaining a complete breakdown of IT costs. This transparency will encourage a better understanding of operational costs by the participating LOBs.

The next natural step would be to devise a model that is agreeable to all. The requests for comments from the first step will be helpful in constructing a common model that resonates with accepted financial practices. Using more than one model in the initial phase will enable a review and analysis of multiple options, encouraging LOB participation. After complete review of the models used, the best model should reflect the most fair and equitable chargeback mechanism that also considers the organization’s overall operational and financial reporting practices.

This straightforward attempt at demystifying chargeback should ensure participation from all business units and surface the operational and financial constraints from inception so that the best chargeback practice will ultimately be selected.

Figure 5. Steps to simplify the chargeback model
Figure 5. Steps to simplify the chargeback model

IT infrastructure governance

Governance in a shared infrastructure is paramount, as resources that are shared by all business units require some level of policy and control that define the boundaries and upholds business unit requirements. Putting these in a Virtual Enterprise context, an LOB might have a requirement for resource isolation that can be accomplished with the isolation preference feature provided by Virtual Enterprise, which enables the dedication of nodes to a specific application or group of applications. With such a requirement, there needs to be governance to ensure that these requirements are adhered to. Chargeback models might reflect the higher costs associated with such a requirement, but governance ensures that the cost allocation is fair. A sound governance policy will ease change management and institute higher confidence in shared infrastructure services.

Governance of an environment that enhances the management of productivity, like a Virtual Enterprise environment, covers areas of ownership, accountability, and access to the operational environment. The key to successful adoption of Virtual Enterprise features is to begin categorizing the features into existing governance models. This way, the clear separation of responsibility is maintained, and any changes can be easily absorbed. Moving forward, new tasks and models might have to be introduced (for example, chargeback and service policy governance) to add to overall IT operational control. Like any change management practice, you should expect this process to occur long term, even to the extent of creating a project to carry out the effort, with active participation from management.


Adopting WebSphere Virtual Enterprise will enable an enterprise to better adapt to the changing needs of its application infrastructure. While Virtual Enterprise provides a platform to adapt to growth, it also necessitates changes and considerations around existing technical and business procedures and policies. This article listed a few important change management fundamentals around Virtual Enterprise. Of course, every environment will be unique in its approach to managing the infrastructure, and the magnitude of the change to the business and its culture will vary.

Virtual Enterprise possesses rich and differentiating features that set it apart as an infrastructure product, plus tremendous business value in terms of server consolidation and manageability features. To leverage these features and realize their potential cost benefits, it is important to identify and engage all stakeholders of an enterprise infrastructure. Any successful change initiative begins with small steps, and a phased adoption of Virtual Enterprise is often best.

This article also presented some of the business challenges that could impact the use of Virtual Enterprise as an engine for a flexible infrastructure platform, and like any worthy challenge, business and technical leaders will have to team up to meet and overcome them. Introducing Virtual Enterprise could involve disruptive changes, but they are changes that are not only necessary but vital to deliver the unparalleled level of quality, service, features, and cost savings that this environment is capable of delivering.


Thanks to Glen Ritchie, Business Value Analysis, IBM, for the original figures and charts.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Taming the business and cultural challenges of a shared application infrastructure using WebSphere Virtual Enterprise