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

LOB-Based Support Model

There are two different ways to implement a LOB-based WebSphere Application Server engineering support model. The first way is to build a technical team that supports multiple technologies and products for one LOB or a large business division. For example, you can build an infrastructure engineering team that supports WebSphere Application Server and other middleware products, the OSs, and the database technologies. Let’s call this model the infrastructure engineering solution team, or to be more concise, the solution support team, because it is the convergence of many different technologies to engineer an IT infrastructure solution for the customer.

The other choice is to build separate infrastructure engineering teams that are dedicated to WebSphere technologies, but belong to different technical organizations that support one LOB or a large business division. For example, you may have one WebSphere team that supports an IT division working for the customer relation management (CRM) department. You may have another WebSphere team that is dedicated to the IT group for your sales and service division. These two WebSphere teams report to different IT organizations in your company. They do not belong to a company-wide WebSphere organization. There are no organization connections between these WebSphere teams.

These two organization models share some similar advantages and disadvantages. However, because there are enough differences, they are discussed separately with the similarities compared from time to time.

Infrastructure Engineering Solution Team

The major advantages of this organization model are flexibility, streamlined support, and ease of doing business for business partners and customers. The major disadvantages are that this form of organization is less developed and it needs work and time to grow and mature.

Advantages of a Support Team of Multiple Products

The relatively smaller infrastructure engineering organization is agile and flexible. In comparison, because of its size and complexity, a large IT infrastructure engineering organization may not be able to plan and implement changes as nimbly. A relatively smaller infrastructure engineering solution team may be able to adapt faster to changing business drivers; therefore, it may be able to do a better job of serving the business. The same goes for a small, separate WebSphere team dedicated to a LOB. Figure 1.2 depicts this support model.

Figure 1.2 Engineering support team of multiple products

Better coordination is also an advantage of the infrastructure engineering solution team. For a product-based support model, you need special teams to coordinate the work of many product-based technical teams. For example, you need dedicated change coordination and environment coordination teams to ensure that the technical teams work together seamlessly. This is especially important during critical system changes, when a good transition between technical teams is critical.

Good coordination is essential in managing large and complex technical environment. When you choose to build dedicated technical teams for each core technology, you want to establish a coordination function to help the technical teams work together. For any of these technical teams, doing a good job as an individual team is not good enough.

For example, during a major system upgrade that takes a long time, if the UNIX^® team fails to inform the WebSphere team to begin WebSphere configuration changes as soon as it finishes an AIX® upgrade, the WebSphere team may not have enough time to perform a complex WebSphere system reconfiguration as planned.

An infrastructure engineering solution team can better deal with work coordination. For this support model, the system engineers for different core infrastructure technologies belong to the same team, and the coordination between them becomes substantially easier. In addition, for such a team it is unavoidable that one system engineer supports multiple core technologies. For example, the WebSphere engineer⁶ may also serve as the UNIX system administrator. Then there won’t be coordination difficulties.

In addition to better coordination, a single point of contact is highly desirable for good work relationships with your business partners and customers. It makes working with your team easier. Remember, from their perspective, the situation when multiple contacts to the infrastructure engineering organization have to be made for technical assistance must never arise.

For example, your application development team may feel burdened if it has to contact the WebSphere team, the database team, the operating system team, the load balancer team, the DMZ team, and the security server team separately to get an application code release planned and executed. A small support team of multiple products can better provide a single point of contact that helps simplifying the engagement process for technical services, and therefore is a major advantage of this support model.

Last, but not least important, is the transparency of cost. It is easier to define a financial relationship with one infrastructure engineering team. When the cost of infrastructure engineering has to come from many product-based support teams, it is substantially more difficult for the customer to maintain a satisfactory performance management metric that leads to a transparent financial relationship.

Clearly, the infrastructure engineering solution model has the merit of simplicity and the advantages associated with a simple structure. However, with its strengths also lies its major drawbacks. The possible problems of this organization model range from technical training pains to major difficulties in managing large and complex projects.

Disadvantages of a Support Team of Multiple Products

Technical training is a big hurdle for a support team working on multiple core technologies and products.

Managing the technical training for WebSphere technologies and products alone is a tough job. Managing the technical training well for many core technologies (for example, the WebSphere Application Server, databases, messaging systems, and numerous operating systems) poses a dire challenge for both the WebSphere manager⁷ and engineers. For example, the technical manager of the team may not have the kind of knowledge and experience to determine the merits of a large variety of training programs proposed for the group. In addition, there is a limit on how many large sets of complex technologies and products that one system engineer can learn.

Another consideration is training budget. Instructor-led classes are arguably the most effective form of technical training, but this is costly. Such instructor-led training is more cost effective to organize for a large WebSphere organization with teams of WebSphere engineers at strategic locations. Usually, such large classes are charged a fixed fee regardless of the number of students, as long as there are no more than 12 to 15 students. Therefore, they are usually substantially cheaper than sending individual students to different classes. A large WebSphere team can reap the full benefits of the efficiency of large classes and the reduction in travel expenditure. For a smaller team, you may have to send individual engineers to classes at differing locations. You have to pay the full class fee and full travel expense.

As a final point, the size of a large WebSphere organization allows several WebSphere engineers to engage in formal instructor-led technical training together. Such training usually takes a week. For smaller teams, it is much harder to afford the time for technical training. It is not surprising that smaller LOB-based support teams can go for years without any formal technical training.

The technical competence of a smaller engineering organization may become questionable. In addition, this is not only a technical training issue. Focused engineering practice and real-world technical experience are vital in building technical competence. WebSphere technologies, as a subset of JEE specifications, are sizable and complex. Therefore, it is a great challenge from a knowledge acquisition and experience accumulation perspective to learn WebSphere technologies alone, to say nothing of learning many such large and challenging technologies at the same time.

If your engineers have to support WebSphere Application Server, operating systems, databases and messaging systems, the technical competence of your team comes into question because of a lack of focus. Your team may become an organization that can skillfully do entry-level system administration chores, but it is powerless when confronted with difficult system and application problems. Being a junior system administrator in today’s highly competitive IT marketplace may not be an ideal position. Your business partners, your customers, and your senior management are more likely to respect and value a highly technical team that can help them survive a difficult IT job.

Finally, recruiting takes more time and is more costly. To hire a good WebSphere engineer is a tremendous challenge anywhere in the world because of the enormous success of WebSphere technologies. The attempt to hire a system engineer who’s good at multiple core technologies, including WebSphere technologies, certainly complicates your hiring strategy, if it’s feasible at all.

Separate WebSphere Teams

As previously mentioned, the other choice for a LOB-based support model is to build separate infrastructure engineering teams that are dedicated to WebSphere technologies, but belong to different technical organizations that support one LOB or a large business division (see Figure 1.3.) Separate WebSphere teams belonging to different IT organizations are a step up from the rather undeveloped solution-based support model. It can better deal with technical training, develop in-depth technical expertise, and grow advanced project management capabilities. This section describes some advantages and disadvantages of building separate WebSphere teams.

Figure 1.3 Separate WebSphere engineering support teams

Advantages of Separate WebSphere Teams

A better understanding of the systems and application of the LOB is an advantage that is also true for a solution-based support model. A separate WebSphere team dedicated to one LOB, over time, can develop a better understanding and acquire in-depth knowledge of both the IT infrastructure and the applications. This is because of better focus and less personnel change between the WebSphere teams of a large WebSphere organization.

These organization models make it relatively easier to develop strong work relationships with business partners and the customer. WebSphere engineering is never merely a technical job. Complex and tough work relationship issues constantly challenge you. As a result, your success is determined not only by how well your team does a set of technical jobs, but also how well you manage your critical work relationships. A support team of multiple products or a separate WebSphere team dedicated to one LOB allows for better opportunities to build good work relationships. The engineers on different teams have an abundance of opportunities to better understand each other working together over a long period of time.

Disadvantages of Separate WebSphere Teams

When you decide to build separate WebSphere teams that report to different IT divisions, you have to consider the development stage of your enterprise IT systems. More specifically, you have to ask yourself what is the scale and the speed with which you are interconnecting your mission-critical enterprise IT systems. If your enterprise IT systems are increasingly interconnected, the LOB-based support model may lead to serious issues. This is especially true in the area of practice differences and system inconsistencies. The flaw of this model is the difference in standards and practices. By adopting this model, there may be different WebSphere systems developed and supported by different teams. This is particularly true if you don’t have a centralized WebSphere planning engineering and process engineering function to make the WebSphere Application Server engineering practice consistent. What’s more, it is extremely difficult and costly to correct such engineering differences and the system inconsistencies that have accumulated.

It is costly to support many WebSphere Application Server systems that are fundamentally different. For example, without a centralized WebSphere organization to enforce consistent system standards, different teams design and develop different engineering processes and automation programs for all the different systems. This can lead to enormous redundancy and inefficiency. Differences in practices, processes, and artifacts become established and entrenched with the development of a business division as well as the growth of its IT systems. As a result, it may be costly if your company decides to carry out any process and system consistency effort.

If you decide to correct these differences by introducing system-wide changes (for example, introducing consistent configuration automation), these differences are likely to derail your effort and may result in serious operation errors and production outages.

For example, one WebSphere team may use the same configuration automation program to make WebSphere system configuration changes for all WebSphere environments,⁸ including development, testing, and production. However, another WebSphere team may do manual configuration in development and the testing environment while using a configuration automation program to make system configuration changes in the production environment. Thus, using the same WebSphere configuration automation program that your company has decided to deploy to all WebSphere systems, different WebSphere teams may have different experiences and results. The team that uses manual configuration in development and the testing environment may not catch the problems with the configuration automation program. This is because of its established engineering process of not using automation in the testing and development environment. This may likely allow a configuration problem go undetected, slip into the production environment, and cause a serious unscheduled system outage.

These engineering practices differences and system inconsistencies make system integration and system interconnection extremely difficult. System standards, such as server naming conventions, can become deeply rooted second nature for WebSphere engineers after years of usage. Therefore, system inconsistencies, such as different WebSphere Application naming conventions and the different assignment of transport ports, can become serious system stability traps and challenges to integrated or interconnected systems. For instance, in a worst-case scenario, production traffic can be sent to the incorrect destinations because of port assignment standard differences.

WebSphere strategy and process work demand significant resources. A small separate WebSphere team may not be able to afford such resources. The lack of resources to work on critical WebSphere engineering tasks such as standards and processes have a far-reaching impact on the quality of product and service delivery for the WebSphere work in your company. In addition, this lack of enterprise-wide guidance in standards and processes in turn makes the system standard inconsistency and process difference problems become worse and more entrenched, thus enabling a negative cycle of deterioration. It is difficult for a small WebSphere team to support the overhead of planning and process engineering.

Summary of LOB Support Models

For an IT organization of a moderately sized company, both WebSphere organization models may work. However, the significant disadvantages of these models may become overwhelming for large IT organizations.

Typically, large IT organizations are more likely to extensively use WebSphere technologies for critical enterprise IT infrastructure. In addition, these large IT organizations have a stronger need to integrate and interconnect their critical enterprise systems. For this kind of IT organizations, a large and unified WebSphere organization with multiple parallel WebSphere teams dedicated to major LOBs may work better. This is especially true if the overall IT organization is relatively mature with sophisticated project management capabilities, established technology delivery practices, transparent cost model, and experienced technical service delivery management.