WebSphere Engineering: Organization Models and Choices

This chapter is from the book

WebSphere Engineering: A Practical Guide for WebSphere Support Managers and Senior Consultants

Learn More Buy

This chapter is from the book

This chapter is from the book 

WebSphere Engineering: A Practical Guide for WebSphere Support Managers and Senior Consultants

Learn More Buy

Building a Global WebSphere Workforce

An open mind and a positive attitude are needed to address the substantial disparity between financial resources available and the quantity and quality of work required for large IT infrastructure engineering organizations worldwide. Determined efficiency and productivity drive help, but they do not alter the resource-intensive nature of IT. IT is still in its infancy. It will take time before IT matures to an adequate level of industrial strength standardization and engineering process automation. Only then can the IT industry significantly reduce its dependency on high human resource consumption. Developing a global technical workforce has been one of the responses to financial and quality challenges. Globalization is a fundamental sourcing strategy, as well as an attempt at product quality and service delivery improvement.

Integrated Team Model

The integrated team model, or mirror team model, implements the concept of global teams incorporating onshore and offshore technical and management resources as each team sees fit in terms of the nature of the work, as well as time and location.

The blanket offshoring approach that hollows out the technical work of a large IT division seems more suitable for application development. Instead, the integrated team model for building a global technical team seems more appropriate for an organization responsible for enterprise infrastructure technology, such as WebSphere Application Server engineering.

The management and technical talents of a large enterprise infrastructure engineering organization belong to the core assets of a large company that has sizable and complex IT infrastructure essential to the continued success and prosperity of the company. The stability of the infrastructure engineering teams, such as support for critical WebSphere Application Server technology, has a direct relationship to the stability of the company’s key IT infrastructure.

The integrated team model approach presents the least disruption to the WebSphere organization and the critical WebSphere Application Server infrastructure. It is important to have minimum organizational and functional disruption while building a global technical force. IT infrastructure engineering and system operations are different from application development. The infrastructure problems tend to be more direct, immediate, and pervasive. As far as application development is concerned, there are usually rigorous testing activities between development and production. Testing, especially stress testing, uncovers and eliminates application code and system configuration defects. Normally, no application code directly migrates to production environment without testing. However, there is nothing standing between your most critical production WebSphere Application Server systems and system operations that your WebSphere engineers perform. For example, the accidental launch of a WebSphere configuration program can incorrectly reconfigure one of your major WebSphere production systems, render it completely unusable, and cause a tremendous enterprise-wide outage. For enterprise infrastructure, especially for large and key technical environments, any disruption is instant, widespread, and serious. The integrated team model helps minimize such problems.

For the offshore WebSphere engineers and managers to be successful, it is critical to help them do a good job at technical training, learn the environments, and know the business partners. One of the best ways to achieve these objectives is to assign them to different WebSphere teams and work with the team for an extended period of time—the minimum needs to be one year. When they know the WebSphere systems, applications, engineering processes, and various technical teams and business partners, it is the right time to reconsider their assignment by fine-tuning the global organization. The integrated team model allows the best opportunity to train offshore WebSphere teammates and give them the best chance to be successful.

This integrated team model gives a WebSphere organization better control and flexibility over sourcing options, as stated here:

• An organization has total control over the scope and degree of this practice and can grow and downsize either onshore or offshore components of the WebSphere organization promptly according to the change in business drivers.
• In addition, this approach gives a better opportunity to directly manage the quality of WebSphere engineers both onshore and offshore via established hiring practices and professional and technical training mechanisms and channels.
• This model allows maximum control over the assignment of the roles and responsibilities of a global team with its onshore and offshore team members.

Long-Term Sourcing Strategy

Building a global workforce must not be taken only as a convenient means of labor arbitrage. Offshore resources will play an increasingly indispensable role in balancing labor costs, accessing rare skills, improving service quality, and reducing service latency.

For example, it is unlikely that all global locations will have exactly the same economic cycles. During a boom time in the U.S., less expensive and relatively more readily available WebSphere resources at offshore locations may be employed at greater numbers to reduce the overall labor costs for your WebSphere organization. In difficult moments of grave budgetary constraints, substantially more WebSphere engineering services can be performed at low cost by hiring more workers with good WebSphere skills at offshore locations. The offshore operations must play a balancing function in the overall WebSphere infrastructure⁹ business.

As a long-term strategy, the cost savings of offshore labor should be secondary. The focus of building a global WebSphere Application Server engineering organization should have other more sustainable objectives. The gaps in salary for onshore and offshore staff and will rapidly disappear. With the extra cost of managing a sizable offshore staff, there could be more costs rather than savings.

As a long-term benefit of globalization, a 24/7 support model is certainly worth exploring. A global WebSphere team and its members at different geographical locations are complementary to each other in engineering support and system operations. For example, China and India have different time zones from those of the U.S. with an 8- to 13-hour difference, depending on the time zones chosen for comparison. This time difference enables a true 24/7 nonstop support system operation, thus reducing human errors frequently associated with late-hour technical support. This helps cut down unscheduled system outage and improves the overall quality of service. The time difference can also reduce overtime payment that a company must make to be compliant with various state and federal labor laws and regulations at applicable locations and further reduce the cost of operations.

Building a local IT organization at strategic high growth locations, such as India and China, can be advantageous, too. This lays the necessary technical organization foundation to support the global growth visions of the company.

In the long run, managing project work and accommodating the real-time nature of infrastructure engineering support is key to the success of a WebSphere team of global workforce.

The WebSphere Application Server engineer has a project management perspective. A majority of change-management meetings, project meetings, and team huddles often occur during normal business hours. The primary WebSphere engineer must attend these meetings. It remains to be seen how this type of work can be effectively managed by global resources.

What’s more, to be an effective primary WebSphere engineer, being able to perform real-time engineering or operations support is critical. The majority of such operations are during normal business hours, rather than at night.

Organizing global resources to support the above mentioned project work and real-time engineering activities and operations eventually determines the size of the global WebSphere team and the amount of assignments for the global team. One obvious solution is to get two or three shifts for the offshore teams to rotate into project work, real-time engineering support, and system operations during local night time. However, hiring and retaining WebSphere engineers anywhere in the world is becoming a great challenge. For some strategic global sites, such as India and China, the competition for WebSphere engineers is white hot. Beijing recruiters have even reached out to the U.S. market for senior WebSphere talents. Any WebSphere manager of global teams knows too well how difficult it is for hiring and retaining WebSphere engineers anywhere in the world. In a tough marketplace for hiring and retaining WebSphere engineers, requesting team members to take night shifts may not be the best way to build and keep a global WebSphere team.

From the perspective of building and managing global teams, there are many interesting and significant organization questions: how far an IT infrastructure engineering team must go to expand a global workforce, what the right balance of onshore, nearshore, and offshore teams should be, and how to distribute the project, engineering, and system support work across the globe.

Although there are no cookie-cutter approaches and there is no one-size-fits-all solution, it is critical that a global WebSphere team be able to engage in end-to-end WebSphere Application Server engineering support, from engagement and design to production operation and decommissioning.

One approach to overcome the difficulty of globalizing a WebSphere organization is to abolish the model in which the WebSphere team assigns a primary WebSphere engineer and secondary engineer to a large project during the full engineering life cycles of the project, and assign a service request system that reaches out to a pool of WebSphere engineers for support. Modern IT projects involving WebSphere Application Server are typically large and complex. Engineering reality is the best test bed for any organizational approach. It remains to be seen if such a pooled WebSphere engineer structure will meet the needs for the timely delivery of quality WebSphere Application Server products and services.