Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Yeshim Deniz, Liz McMillan, Pat Romanski, hyper filter, Timothée Bensimon

Related Topics: Software Configuration Management, WebSphere

SCM: Article

WebSphere Migration: An Approach for Success

WebSphere Migration: An Approach for Success

The popularity of distributed computing has gained tremendous momentum over the last three years. Much can be attributed to the maturing of two intricate parts of the solution: the Internet as network solution architecture, and application server technology. One of the more popular application server technologies in the marketplace is IBM's WebSphere application server solution.

Based on my experience, this article discusses some technological and organizational issues that arise when migrating to WebSphere application servers. Whether you're migrating from another application server or getting into application server architectures for the first time, there are a few basic areas that must be examined, and solidified, to ensure success.

Too often companies take a client/server approach to application server development. They allow these servers to proliferate across the enterprise based on division or unit requirements. Application servers differ from a client/server environment in a number of ways:

  • In a client/server environment, the majority of applications are developed by development professionals. Individuals need a certain level of sophistication in order to use the tools. With Web-based development, there can be many levels of development, from end-user in HTML to sophisticated Java development.
  • Because these applications are designed for Web-based architecture, your application could be accessed by a large audience, perhaps in the millions, whereas in a client/server architecture the number of users could be controlled and managed by either the DBMS or the application itself. So although a Web-based architecture allows certain freedoms, it has the potential to create a performance bottleneck if not architected correctly.
  • For the most part, client/server applications dealt with the presentation of data (i.e., data queries, etc.) to a predesigned GUI interface. The technology limited the potential for multiple "data types" within the application. Web applications tend to be very content-rich. Because of this architecting for performance in a browser-based solution, using application servers becomes the number one priority. Content presentation as well as management and network caching must be taken into consideration.

    Most transaction-oriented Web applications are what I term virtual applications: multiple instances of that application may be running across multiple application servers. How you manage applications changes, updates, and performance become strategic to the success of the application. This is quite a bit different from a client/server architecture where the focus is on managing database access. Applications are not the concern. The database takes the priority.

    When beginning this migration process, here is how I've seen this introduced successfully. The computing enterprise should be looked at in terms of:

    • Operations architecture
    • Technical architecture
    • Development architecture
    • Application architecture
    Operations Architecture
    Operations architecture is a framework describing the collection of hardware and network components, operating system-level software, and operations architecture processes/services that comprise the production application workload. It encompasses security management, storage management, disaster recovery, configuration management, and performance management.

    Why do you need operations architecture? As you move to an application server/netcentric model, you'll rely more on your enterprise servers and mainframes. Since you're moving to a netcentric model, I'll assume you'll have proliferation mobile devices, including wireless, and are maintaining service levels to your customers while managing change. As we discuss the migration process in more detail, you'll see the importance of this architecture in managing the application server.

    Technical Architecture
    Technical architecture defines the common runtime technical services upon which an application executes in a production environment. Technical architecture is concerned with:

  • Increasing developer productivity: Developers avoid reinventing the wheel when technical architecture defines a common development platform and a common source for technical services.
  • Maintaining consistent application quality: Inconsistent adoption of common technical services leads to inconsistent application behavior and quality, resulting in applications that are more difficult to build, use, and maintain. Technical architecture seeks to resolve this problem.
  • Reducing time-to-market: Technical architecture can reduce time-to-market of new business capabilities by using standard architecture services, adhering to industry standards, and making consistent tools and implementation techniques available.
  • Controlling impact of product changes: Because no one vendor has a complete solution for a netcentric architecture, multiple vendors and applications need to be integrated. Changes from a vendor can severely affect your systems.
  • Increasing complexity of business systems: Technical architecture can help manage complexity by providing common technical services developed once by skilled personnel who can understand the current state of technology and anticipate its future.
  • Integrating systems within and between businesses: It fosters solutions with a higher degree of integration by helping tie together disparate software, platforms, and protocols into one comprehensive framework.

    Development Architecture
    Development architecture defines the approach to developing business systems. When methodology, tools, and environment are defined, there is a reduction in the complexity of developing in a netcentric environment. Development architecture focuses on these issues:

  • Consistent developer tools: In the Web market, the multitudes of development tools and their inability to work together can have a severe impact on version control, as well as testing and Q/A.
  • Ease of training: How complex or easy is it to learn and implement the development tools? Are there tools for the end user as well as the developer? What is the learning curve on the tools set?

    Application Architecture
    Application architecture is a framework describing how the user channel, business processes, and data layers will be organized to support business capabilities. Application architecture provides a common framework and vocabulary for analyzing application systems, and the business implications of such systems, in order to standardize them and minimize duplication throughout the enterprise. The interrelationships of these layers in a fictional company are shown in Figure 1.

  • User layer: The user layer provides the channels through which internal users (the crew) or external users (the clients) may access the company's services. A variety of channels, such as Web access, Voice Response Units (VRU), workstations, and paper mail enable users to do business with the company.
  • Business process layer: The business process layer provides an enterprise-wide view of the processes required to perform the major business functions/capabilities, and how such processes interact with users and external parties. The business process layer ensures that applications support specific business capabilities. This layer is an essential component that allows solutions to be aligned with business needs.
  • Data architecture layer: The data architecture layer defines the business entities and relationships that support the business requirements, and represents the hierarchical breakdown of data from the enterprise level to the application level. In essence, the data architecture layer describes what information is necessary to complete a process. It supports the application architecture by providing an integrated enterprise-wide framework to allow for shared corporate data. This layer is the overall blueprint for properly organizing and managing the data and information.

    The application architecture outlines a framework that allows the business to communicate more clearly with business units and shareholders, and to act more efficiently on their behalf. By addressing the IT challenges listed above, the Application architecture can provide the following benefits:

  • Provide a common business definition and communication framework for IT and the business units.
  • Assist in determining the impact analysis for new business capabilities.
  • Identify strengths and weaknesses in applications based on business requirements.
  • Promote sharing common processes across business units and working in unison to develop a migration plan to the future.

    Plan to Implement Architecture Tasks
    When planning a migration, each of these considerations should be reviewed relative to the WebSphere architecture. Below, I've listed some tasks required for each architectural area.

    Operations Architecture
    1. Review, analyze, and document prototype architecture for intranet and extranet applications.
    2. Understand the WAS configuration management, product and application upgrades, capacity management, security management, event management, disaster recovery, and performance turning.
    3. Examine the design and testing of an automated installation of a WAS on to your production platforms.
    4. Begin defining an operations production environment and the associated processes that support your intended platforms: Unix, NT, etc.
    5. Begin testing the automated start, stop, and restart of the WAS and its dependent processes (NES, Configuration Database) in an orderly fashion.
    6. Test fault and event management integration into the existing network system management environment. This includes an identification of fault/event meanings and the appropriate actions.
    7. Test WAS Network and route diversity and reachability.
    8. Test or create processes for automated replication and load balancing.
    9. Design associated with business continuity (disaster recovery, or DR) and high availability.
    10. Design and evaluate performance and capacity measurement and management.
    11. Begin assessing and making recommendations on the capacity forecasts and processes used as part of storage management.
    12. Begin assessment of the impact on the workload job scheduling process to determine if a review and rework is needed.

    Development Architecture
    1. Evaluate, design and implement software configuration management processes such as software build, compile, link, and register, as well as application promotion processes and procedures for WebSphere from development to production elevation.
    2. Design, implement, and document software version control prototype processes.
    3. Design, implement, and document prototype services that manage and control configuration, global and properties settings.
    4. Design and implement prototype services to manage the porting of security LDAP rules.
    5. Evaluate, design and implement performance-tuned compilers for WebSphere, i.e. Java HotSpot compiler.
    6. Design, implement, and document best practice processes and procedures for runtime environment provisioning and retirement.
    7. Develop a working model/prototype in support of technical engineering services and application programs identified for initial deployment.
    8. Evaluate and deliver tools and training materials in support of WebSphere datastore registry LDAP, Oracle, DB2, etc.) load processes.

    Technical Architecture
    1. Identify and define test-case scenarios, including system configuration, input data, and results analysis, as well as component-level performance testing of applications developed to run on WebSphere's latest release.
    2. Upon release of WAS Service Pack releases, identify and define test case scenarios including system configuration, input data, and results analysis , and then define test execution of component level performance of applications developed to run on the latest release.
    3. Define the integration and develop implementation procedures for deployment of applications to run under the WebSphere architecture.

    Application Architecture
    1. If migrating from another application server, then begin investigation into application migration, including code reviews, best practices for WebSphere application development, and education.
    2. Begin evaluation and investigation into content management processes for WebSphere and personalization technology.
    3. Identify, recommend, and document strategies for configuring and deploying WebSphere-based applications into multiple environments.

    First Things First
    The following are items I lbelieve are priorities. If you can do nothing else, at least focus on these items:

  • Develop Configuration/Release management procedures to support the netcentric integration/promotion model.
  • Create standard procedures for source code control within the WebSphere domain.
  • Evaluate common environments to host intranet and Internet applications.
  • Evaluate HW, SW, and network configurations to support test environments.
  • Evaluate network configurations to support development, test, QA, and production environments as well as high availability, load balancing, data recovery, and WebSphere coexistence with competitor application servers, if required.
  • Ensure that system management is configured to support process monitoring, shared logging, and Tivoli integration.
  • Evaluate data architecture for WebSphere datastore requirements (Oracle, DB2, Sybase and LDAP).

    Establishing a Center of Competency
    Of course, none of this works unless your organization is supportive. I recommend assembling a center of competency for WebSphere implementation. The COC could follow the model shown in Figure 2.

    The purpose of a center of competency is twofold: it creates an area of expertise to deal with problems as they arise, and it can be the basis for a strong mentoring program. I'd recommend a staffing model similar to this:

    • Center manager
    • Full-time e-design integrator
    • Full-time WebSphere architect/mentor
    • Part-time WebSphere architect/mentor
    • WebSphere developer/mentor
    • Part-time education consultant
    • Part-time product technical specialist
    • Release management specialist
    • Part-time release management specialist
    You may have to go to IBM consulting or to a business partner to get the necessary expertise to assemble this center. keep in mind that WebSphere is a powerful but sophisticated solution that was built as a way to run your business. You must treat it as such, and roll it out slowly with an extreme emphasis on testing and quality assurance. Take your time and be cautious, and WebSphere will give you the ROI you expect.
  • More Stories By Robert Costello

    Bob Costello is an application architect with more than 15 years of experience in application development. He can be reached at [email protected]

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.