Home > Articles > Web Services > WebSphere

  • Print
  • + Share This
This chapter is from the book

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

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 engineer6 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 manager7 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

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,8 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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020