IBM is known in the industry for releasing software products that are tremendously powerful yet tremendously complex; unfortunately, because of the latter their software installations are sometimes quite difficult. Actually, in their defense, "are" is quickly becoming "were." IBM has been putting forth quite an effort to revamp and fix the installation challenges that developers and consultants have seen in the past. This Pro-Spective will attempt to touch upon the major recurring issues with IBM installations, both in the WebSphere suite of products and others, and look at how IBM is aggressively pursuing solutions so that these issues will be a mere thing of the past.
Fool's Gold
Everyone remembers the "worksheet" you had to fill out for WebSphere Portal Server v4 to prepare for the droves of configuration options that the installation would require. This step-by-step manual, which could be ordered on CD or downloaded (and which was supplementary to the regular Portal documentation), walked a user through the installation; it explained each and every option up front, gave examples for most options, and let the user create the configuration before attempting the installation. Due to its success, this worksheet quickly became a critical companion for most installers. It helped avoid many installation issues that would cause the lengthy installation process to have to be restarted.
Unfortunately, the procedures for correctly cleaning the machine after a failed installation were poorly documented. Granted, the Troubleshooting Guide did provide a list of potential errors you might receive during an installation, but it wasn't exhaustive. So it was possible to generate an invalid "worksheet" configuration, have the installation fail with an unknown error, and then have to recover via (mostly) trial and error.
The most common complaint, however, from end users and/or clients using Portal version 4 was that the installation tried to lay down a complete IBM solution: IBM HTTP Server (IHS), WebSphere Application Server (WAS), DB2, Informix Dynamic Server (IDS), and WebSphere Portal Server (WPS). Only after you installed everything (assuming there were no conflicts with similarly functioning existing software), could you run a couple of configuration scripts that could move parts of the infrastructure to other vendors, such as LDAP to Active Directory, or DB2 to Oracle. The point is that the initial installations of certain parts of the IBM stack were not useful because clients were going to move to other vendors for their business reasons anyway.
Another IBM product, Content Manager, shares some of the same installation issues as Portal as well as introduces new ones. Before Content Manager version 8.2, it, like Portal, also suffered from having panel after panel of configuration options, which was simply overwhelming for amateur users. The problem was exacerbated for new users because if they were unfamiliar with the product or its dependencies (such as DB2) it might have taken several hours to research the proper values for all the fields on all these panels. If a user was able to install the product, the values entered sometimes resulted in an invalid configuration; the installation succeeded, but the program didn't run.
Because of all these different factors the installation processes for certain products were sometimes reduced to little more than trial and error processes, which beg us as developers to ask the tough question: should products really require experts to install?
Rags to Riches
Those are just two examples; there are others. The emphasis should not be on things that were done wrong, but instead on what lessons can be learned to enhance the experience for end users in the future. It is well understood that IBM has extremely complex products that need to be integrated into highly complex, heterogeneous environments - so it's no wonder that the installation process is overly complex and not necessarily intuitive. With experience, like that mentioned above, and critical user feedback, which is provided continuously, IBM has taken a serious look at this problem and has recently come up with at least one solution that will be making its way onto the stage soon enough. It is called Integrated Runtime (IR).
A Quick Fix, for Now...
IR is an impressively fast response to the problem that IBM faced, and that's because it operates primarily on the principle of data hiding; it does not attempt to, nor does it want to (at this point in time anyway), change the actual installation procedures. Its focus is to put the installation issues into the hands of experts for each product. These people have gathered knowledge and have experienced installing each product on different platforms. They are best able to aggregate all of this knowledge to produce reusable "wrappers" that sit on top of the existing procedures, providing customized installation scenarios; in other words, preconfigured solutions (with all the bugs and kinks worked out, hopefully).
IR's current version is 1.1, with an upcoming 2.1 release targeted for the end of Q1 2005. Figure 1 gives a high-level look at how IR is designed. It can be broken down into two primary units: application wrappers and solution wrappers. Each of the units work together in a cooperative fashion as a single solution: the application wrapper controls the execution of one or more existing installation scripts as well as possibly one or more pre- or post-installation procedures; the solution wrapper coordinates one or more application wrappers to provide a solution that can potentially integrate any number of products, of any version, on any set of platforms, with each other.
Application wrappers facilitate reuse within and amongst product teams. Looking forward, if all teams opened up their respective installations through wrappers (instead of having experts come in and fix the issues for them), it would reduce the time necessary to perform integration testing because the tasks would be broken down into smaller and more manageable pieces that could then be reused in this framework provided by IR for other solutions.
Not only does a framework like this one enable a clean and consistent interface to the installer, but it also abstracts away the concept of separate installation logs and installation error codes. Since everything now gets installed through this framework, everything would also report to it.
In fact, to reap the most benefits, it should be the responsibility of this expert team to break any tasks that are specific to integration out into separate wrappers, which could be included in different solutions as necessary. Figure 2 shows a product map where the numbered lines are these procedures, which integrate their respective endpoints.
According to the diagram, an integrator can presume that if IDS and DB2 were packaged as a single solution it would require only two application wrappers - one for each product, more clearly shown in Figure 3 as Solution Wrapper A. It is easy to see that none of the integration wrappers are needed because there aren't any lines between the products in this solution wrapper.
However, if a client wants to install Portal and have it integrated with either of the aforementioned products, it would require four application wrappers: two for the WPS/WAS combination, one for the other product, and one more for the integration piece between them. Solution Wrapper B in Figure 4 shows what this Portal-DB2 integration would look like; the line labeled 3 corresponds to the application wrapper that encompasses the integration tasks required to properly fuse the two products together.
By wrapping the core installation procedures for each product separately from the procedures needed for integration, providers may recombine products and/or components as they see fit for redistribution as highly customized solutions for clients.
Lastly, by installing products within this framework, the concepts of platform and location fade. As far as the wrapper is concerned, it does what the framework tells it to do. Since the framework supports distribution across machines comprised of a heterogeneous set of operating systems in different geographic locations, wrappers written to work within that framework automatically gain that flexibility as well. This allows for a zero effort transition from a local installation to a remote one; in fact, it allows for a single machine to coordinate the installation of products across a variety of machines at the same time.
Problem Solved?
But what do developers of installation scripts really have to worry about? Is it important to keep in mind that multiple products may integrate with the operating system, or an LDAP, or even a third-party program to provide security? Should time be spent to ensure that products from a single vendor cooperate and/or share some values to provide an integrated service? Is it important to be mindful of the developers and consultants who will want to install multiple versions of the same product on the same machine, thus requiring investigation into co-existence issues? Yes and no.
It is true that all of these issues are important, but I argue that they shouldn't be pushed to a separate group of people to write the actual installation scripts or application wrappers. Instead they should be owned by the actual development teams who have the deep product expertise to ensure the products work together in an integrated environment. Integration is not going away - it is becoming more prevalent.
Looking Forward
Integrated Runtime should only be looked at as a temporary fix because this solution doesn't truly eliminate the installation issues seen in the past - it only hides them. Don't get me wrong, the idea of wrappers and abstraction is good, but wrappers alone aren't providing a complete solution. This framework will have greater impact when the proprietary installation procedures are replaced and/or removed from the equation altogether.
The ideal solution would be for the development teams to collaborate on the interfaces that their products will use to communicate with one another; moreover, each needs to provide a separate and convenient, yet consistent, way for the installers to write the scripts and/or wrappers on top of them. The key is agreement. They all need to agree.
Having a solution that is overwhelmingly different from how things currently operate cannot be implemented quickly.
Most likely IBM will use a hybrid solution: wisely continuing to invest in Integrated Runtime while at the same time passing down specific suggestions and requirements to the product groups. As the issues are addressed closer and closer to the root of the problem, IBM's installation procedures will become more and more flexible and configurable. Stay tuned...down the road, I'm sure they will become as impressively robust as the products they are installing.