WebSphere

Digg This!

Ah, the good old days of data processing - the days when Unix developers worked on Unix, Windows developers worked on Windows, and mainframe developers stuck to the big iron. In those days, each group could gather around its own water cooler and make fun of the developers working on the other platforms.

The Unix team would make fun of Windows' reliability; Windows developers would make fun of the mainframe's outmoded technology; and the mainframers didn't care because they controlled the company's mission-critical business applications. Developers simply never talked to each other. Then along came WebSphere and everything changed.

WebSphere provides a standards-based application environment in which data and functions can be shared across applications. Empowered users access necessary functions and data regardless of the data's location or the application's operating platform. Users can enable their CRM system to display current order status from the billing system, work-in-progress information from the production control system, or the order history for a particular customer across all divisions and subsidiaries. Today's IT buzz is about how this form of greater enterprise application integration (EAI) can dramatically improve the productivity of an organization by providing universal, secure access to critical business functions and data to end users through simple, familiar interfaces. WebSphere provides the infrastructure to make EAI happen.

WebSphere and the Challenges of Greater EAI
To successfully implement EAI using WebSphere, however, requires changes in how IT has traditionally operated. As usual, making things simpler for end users complicates the work of IT. IT staff members can no longer operate in their isolated, platform-based silos. Suddenly, everyone has to communicate and collaborate. Changes to the mainframe database might require changes to the Unix applications using the data or to the Windows applications displaying it. New application functions need to be announced broadly, allowing interested users to take advantage of them and to avoid needlessly duplicating work in the future. Enhancement requests and bug reports in shared systems must then be centrally organized and prioritized for implementation. Deployments of updates may need synchronization across platforms. The list goes on.

These complications might concern IT less were they not already struggling to provide a high level of service to the enterprise. Currently, according to Aberdeen Consulting (and known intuitively to most of us in IT), 90% of completed IT projects are late and 30% are cancelled prior to completion. According to Gartner, 50% of IT projects come in over budget (by an average of 44%) and 50% fail to meet their intended business objectives. Addressing those problems while taking advantage of the new integrated application environment requires a change in how application projects are managed. So now enterprise application integration requires enterprise application management (EAM).

The Case for Greater Enterprise Application Management
To deal with diverse development teams, a multitude of platforms, and the resulting integration issues WebSphere introduces, many IT organizations have started down the road to greater process management. According to META Group, 5% of Global 2000 companies currently have an integrated IT governance program under way. They expect that percentage to increase to 40% by the end of 2004 and to 70% by the end of 2006. Although most current methodologies and tools employed for managing the WebSphere development process are ill-suited to providing full-fledged EAM (see Table 1), a new generation of practices and solutions are now targeting this need.

The development shops now actively applying EAM to WebSphere are, in reality, adapting time-tested, documented practices of manufacturing process management for software development. The ideal EAM setup allows IT management to describe the rules they want applied to actions and interactions during the application development, integration, and maintenance process, and then enforces and automates those rules across all environments and teams. At its simplest level, EAM means freeing programmers from repetitive clerical tasks that might otherwise be required to avoid introducing defects. On a more sophisticated level, it means establishing and enforcing the rules during the entire development life cycle, including software development, testing, and support. As the process evolves, automated documentation of the activities enables the organization to continuously evaluate and refine development practices (see Figure 1).

The objective is not to become bureaucratic, but to establish practices that have repeatedly proven to increase the output and quality of most development groups. Adopting recognized standards of process management (as reflected in EAM) and the myriad tools to support them, programmers have frequently found that instead of constantly working on damage control for problems caused by greater personnel and systems integration, they now have more freedom to engage in the creative aspects of their profession. The crucial challenge is to put in place the appropriate combination of personnel, procedures, automation, and structure that will allow IT to continue to rapidly deliver high-quality applications and leverage WebSphere's entire feature set.

A Basic Outline of Enterprise Application Management
There are several elements critical to successful enterprise application management. They are:

• Total application lifetime management
• Enterprise inventory management
• Life-cycle process automation
• Release management
• IDE integration

Total Application Lifetime Management
Most of the tools used for managing applications today focus mainly on the initial development of an application. However, studies show that the typical IT organization spends four to seven times as much on maintaining an application as they did on its initial development. In an enterprise's WebSphere-run application, there will be multiple components representing many different stages of an application's lifetime, not just the initial development stage. A typical example is a mainframe COBOL application that has been running for years now trading information via XML and/or Web services with newly created Java applications running on Unix or Windows servers. In order to manage these applications together, users must have a system that can assimilate work in progress across current applications as well as new development, and also tie those components together.

Enterprise Inventory Management
The heart of any management system, whether it's a warehouse system, a payroll system, or an enterprise application management system, is a detailed inventory of all the parts it manages. Because the WebSphere environment can contain so many different parts from so many different platforms, building a central inventory poses a major challenge. The EAM system must keep track of the current location and status of all the application parts and control access to those parts regardless of file type or ultimate destination. Since these files can come from multiple platforms with varying storage architectures, the latest systems typically store these resources in a secure database repository such as BLOBs (binary large objects). Database functions like commitment control and constraints protect the database from corruption. Storing the files in a database significantly simplifies backup and recovery.

Once the files are stored in a database, an EAM system needs to provide powerful functions for organizing and exploring the list of parts. Multi- platform WebSphere applications have extremely complex storage structures. In order to find the files of interest, a user might need to know the Unix directory structure, the Windows directory structure, the WebSphere directory structure, and the mainframe library structure.

Even developers can find it challenging to find files that way. But what about the managers, testers, operations people, and others who need to work with the application and who are likely to be unfamiliar with these storage structures? They will want to see all the files in an application regardless of the platform, directory, or library in which they reside. A QA tester might want to see all those parts currently in QA. A project manager might want to see where all the parts of a particular release or enhancement are in the development life cycle. Before a deployment, operations might need to review the list of parts and the target systems to ensure the installation is scheduled properly. An EAM system must maintain a metadata database with detailed information about the current location and status of every part under its control so that the user can find the list of parts they need easily.

Life Cycle Process Automation
The basic principles of total quality management teach us that in order to build anything of high quality - whether it is cars, houses, furniture, or software - you must first create a structured, repeatable, measurable process for building it. For application management, that means defining the entire process of what happens from the time a request for a change occurs until the time the solution is deployed into production. There will be workflow procedures like requirements gathering, design, review, and approvals, as well as code movement processes like checkout, promotion, and deployment.

The reach of an enterprise WebSphere application means that many people from different parts of the organization can feel the impact of a single change. To provide high-level customer service, the workflow rules must include notification to end users of the disposition of their requests and of system changes that will impact them. Keeping users up to date on the progress of IT projects (and delivering those projects on time) will go a long way toward reducing end-user anxiety and improving their perception of IT service levels. Putting in place approval procedures to ensure that ad hoc requests are not added to the project schedule without management acceptance will reduce project delays. Setting approval rules that allow end-user managers to sign off on moves to production that impact their departments will ensure that IT does not disrupt business operations by performing a system update at an inappropriate time. An EAM system can automate these processes so the appropriate people receive notification when they have a task to perform.

Once a change is approved, the project must move through the organization's move-to-production life cycle. Most of the first-generation tools for managing software development, like CVS, expect the management of that process to be either a manual function or a function automated by ad hoc user-written scripts. Both of those methods are potentially costly and error prone.

An EAM system allows users to define the rules that govern the move-to-production process up front. From the beginning it automates and enforces those rules. The user need only identify what to move. The system knows where the parts are, where they need to go, how to deploy them, and how to install them. Since there is always a trade-off between the amount of testing and the speed to production of a change, users can define life-cycle processes that make sense for each application. IT organizations implementing this kind of structured, auditable process ensure they always know about every change and how it got into production.

Release Management
In an enterprise application, managing releases can take many forms. For example:

• Local customization: If an organization has locations in different states or countries, applications will probably require some level of local customization.
• Mixed short-term and long-term projects: When maintaining mature applications there will be times when it will be necessary to manage large updates while still allowing for small maintenance changes to occur. These changes will need to move through different life cycles to ensure they don't interfere with each other.
• Staged moves to production: In an enterprise-level Web application, it may be desirable to gather sets of enhancements and fixes together into a package that will be deployed as a unit. There may be several of these packages in development simultaneously. These packages must move through the life cycle as units of work. They may not necessarily be moved serially, allowing users to deploy them as needed.

With an effective EAM system, all the user needs to know is which release requires work. The EAM system knows where the parts are, where to get the appropriate versions for checkout, where to move the code on check-ins and promotions, and where to deploy all the files. The system will automatically move the parts through the appropriate testing stages for the release to which they are associated. It will take care of notifying users when a change in one release must be reflected in other releases. And it will provide tools, as necessary, for merging releases together.

IDE Integration
There is an adage that says, "if the software process management system is not easy to learn and use, programmers will be very creative in not using it."

In the WebSphere environment, it is critical that developers can work from within the WebSphere development environment. Fortunately, IBM anticipated that requirement and built the WebSphere tools on top of the Eclipse Framework. Developers or vendors that want to integrate with the WebSphere tools simply need to create plug-ins to the Eclipse environment. An EAM system should be implemented as an Eclipse "team repository," meaning users can access the parts or resources under management through any standard Eclipse perspective using standard Eclipse functions. Checking out, promoting, adding, refreshing, deleting, etc., are all likely accomplished by simply right-clicking on the desired files in the chosen perspective and selecting the appropriate option from the pop-up menu. There is no need for developers to learn or understand the whole underlying management process. Developers get all the advantages of change control without sacrificing the ease of use and productivity of working in their IDE.

In fact, this is really what an EAM system provides for everyone. The idea is that each member of the team can access the system through a view that makes sense to him or her. Developers can see things through their IDE, project managers can look at a project-based view, operations can view things from a deployment package perspective, and executives can see a high-level summary of activity. All they need to know is what functions they want to perform or what information they require.

Conclusion
An enterprise application management system is the necessary infrastructure that will allow organizations to take advantage of the promise of enterprise application integration offered by WebSphere. An EAM system provides a single point of observation and control that allows users to implement consistent processes across the enterprise and provide management with the information they need to meet their quality and delivery objectives. By automating the day-to-day administrative functions, it frees up developers to concentrate on building applications. Its central repository of information about application development and maintenance efforts ensures that everyone is aware of activity that might impact them. In a complex WebSphere environment, an EAM system serves as the plumbing that will allow IT to consistently deliver high-quality applications that meet end-user requirements on time and within budget.