Synopsis:
Discusses the issues involved with planning and managing the implementation of new client-server and Internet technologies. Topics include infrastructure development; implementation pitfalls; support for implementation; advance project management; and criteria for designing a prototype, pilot, and test plan. The approach emphasizes the authors' creation of a case study of a hypothetical business that develops client-server, Internet, and intranet technologies. Annotation c. by Book News, Inc., Portland, Or.
From the Inside Flap:
Preface
"Since we happen to be at the beginning, let's begin here." -J.R. Lakeland
There is an interesting phenomenon today in the computing industry ( I mean other than Bill Gates). There has actually been a small rumbling of what could be considered a ground swell to reverse a technology paradigm shift! I've been in computers for twenty years, and I don't recall this happening before. But I'm way out ahead here so let me back up a decade or two.
The late 1980's saw a new paradigm being introduced. The old paradigm was the monolithic computer, and the associated functional but deadly boring terminal screen. The shift was to client-server computing: the use of one computer or class of computers to act as a computing, data, or application server while another computer or class of computers provide client services. An example many people will be familiar with is the typical on-line service where the screen and editing are being provided by your desktop PC, but the look-up data is maintained on the server end. The two applications speak to each other transparent to the user, as opposed to filling in a screen, pressing enter, and waiting (although even that can be client-server in a very loose model).
Client-server computing is meant to put the processing power where it is needed, thus reducing the need for humongous mainframes and allowing the provision of meaningful information to the user like never before. Sounds great, no? Many CIO's believe so, and showed it by `betting the farm' on client-server technology.
This "ground swell" movement is suggesting that a move back to the mainframe might be appropriate. Why? If client-server technology is so wonderful, why move back to the mainframe? Why even consider shifting the paradigm back with the cost of losing what the shift was supposed to provide, let alone the cost of the reversal? Why do cubicles have signs like:
Mainframes: We're back, and boy are we ticked off! Aside from the fact that the local mainframe sales representative probably photocopied a stack of them and left them around, what would lead to the display of these signs? There is a perception that the client-server paradigm isn't working. I agree to some extent, but not for any reason that would have me advocate people returning to mainframes, the `art' of 80-column JCL, and data in the form of reams of green-bar paper instead of information.
Let's not lose sight of the Internet earthquake, and the aftershock of Intranets. Lest we forget, both are examples of client-server technology, and there's not a darned thing wrong with it. There are ongoing issues with the application side of client-server technology, but before I discuss the cause and solutions, let me expand on the symptoms of the issue.
Symptoms
the technology is expensive to manage the applications are expensive to develop payback is lacking Frankly, these symptoms were common long before client-server technology. The inference is that client-server technology itself is the cause of these symptoms. Untrue. The cause is often that much of the planning and implementation to insert client-server technology into these mainframe environments was done by people who had as much idea about implementing it as does my Clumber spaniel, Bumble (and when you look deep into his eyes ya don't see much client-server knowledge), and sometimes that those responsible for its implementation had considerable motivation (they felt) to not have a successful implementation.
The truly amazing, and often humorous, slant to all of this is that the client-server naysayers seem oblivious not only to the fact that client-server technology is enjoying an enormous success, but that often this success is happening right in their `living room.' They look at the PC with the order-processing application connected to a server and say that it should move back to the mainframe, but all around their company people are using the Internet, and possibly an intranet, and the fact is folks that the whole technology of web pages on a World-Wide Web, in the case of the Internet, or on an intra-company server, in the case of an intranet, is client-server technology! I think that needs to be stated again:
The Internet and intranets are the successful embodiment of client-server technology! There, the secret is out. Yet nobody is screaming about the Internet not working. No one is saying that intranets are a waste of time. Just the opposite is happening — Internet Service Provider (ISP) stocks are increasing steadily and anything having to do with the Internet from add-on applications to magazines seem to be a gold mine. Is it simply because the technology is so new that no one understands it yet? Nope. So why are the client-server applications getting bad press? Let's go back to looking through the eyes of Bumble the Wonder Dog. What happens when you launch into anything major in life with the combination of insufficient information and little experience? Consider that combination coming to bear in constructing a house or starting a business: would you want to live in it or work for it?
Let's take a look at why these problems are really arising.
1. Politics and empire. Don't underestimate it. He who held the mainframe held the power. In many cases the power base of a distributed computer system, as is the case with client-server, is unclear. So there are instances where the `emperor' is concerned with diluting the powerbase and so, despite giving the go-ahead on a client-server project due to politics there is no desire for that environment to succeed. In other cases, political opponents of a well-meaning CIO (Chief Information Officer) see the large-scale implementation of new technology as opportunity for a covert toppling of the existing powerbase.
2. CIO's are being misled, intentionally or unintentionally, about the return on investment of client-server technology. The fact is that the technology and development using it have a front-end loaded cost. Implementing an environment of new technology is always costly, as is the learning curve and configuring of the development environment. New equipment has to be purchased; new infrastructure developed or the current infrastructure heavily modified; libraries, databases and objects need to be designed before anything is rolled out let alone a return realized. Therefore, the ROI (return on investment) is weighted towards the back-end on a timeline.
3. People are losing sight of the biggest ROI ( eliminating the huge mainframe dinosaur. The intention, when the environment is agreed to, is usually to develop a migration plan to get off the dinosaur. What happens very often though is that an inordinate amount of time ends up being spent on GUI's (graphical user interfaces) for applications because they're visual, have immediate impact, and feeds our apparently inherent need for creeping elegance. So the user ends up with just an e-mail system with an above-average paint job, though the billing and purchasing systems are still on the mainframe, thus leaving the mainframe expense intact.
4. Infrastructure. Hardly anyone is giving it the proper consideration. You might be able to force a round peg into a square hole, but then both the hole and the peg become fairly useless. The thought very often is "the mainframe infrastructure has existed for years — let's use it." Well, you may not be able to bend and shape it enough without major changes — even a Slinky® has limits to its adaptability.
5. Deployment. There are many approaches to deployment, especially when those deploying are unfamiliar with the technology. Often brute force is used. It works, but not well, and can result in positioning the landscape of a very different ROI model without anyone realizing it.
Given these points of potential failure, I should now provide my rationale in developing this book, and first, why I felt what I have to say is worth reading.
I began managing enterprise-wide rollouts fifteen years ago. I didn't make a conscious decision to enter this arena; I was a software developer and stumbled into it. At that time the new paradigm was mini-computers used for financial, order processing, manufacturing, and so on. Having designed a research and manufacturing application for a chemical coatings company, I found myself responsible for implementing the technology and applications at multiple sites. Many of the issues in that rollout arose in every subsequent one, albeit with different faces and packaging, and had nothing to do with the application itself, but instead the infrastructure necessary to support it. Through the many implementations I have planned and managed since then, with magnitudes ranging from a handful of systems to upwards of a thousand, and clients including telecom corporations, two of the largest retailers, and a major media corporation, I've developed what has been for me a sanity-saving approach.
It's the approach I want to pass on to you, and a case study and specific technology example is the method I'll be using. Back in my college days my roommate and I made the not-so-bright decision to drive from our school in Connecticut to his friend's school in New Hampshire, during a frigid New England winter, in a car without a working heater. I remember us slip-sliding along what looked like a small highway on the map, but in reality translated to a path through the mountains. We stopped at a roadside general store and I asked an old gentleman for directions (yes, honey, I actually did that once). He responded with the classic, "Ayuh, ya can't get there from here." Well, looking around at your environment, and then looking at an environment where client-server applications are being used to their potential, including the use of an intranet, might leave you feeling that you can't get there from here, but you can, and I'm going to try to give you directions. I'll also try to provide a map of the pitfalls along the way. At times it might sound very negative, but that's only because all the pitfalls need to be mentioned, even though you might not experience them, while the good stuff that will hopefully happen to you along the way is left to your imagination.
The bottom line: plan for the planning. Because most of the issues facing an enterprise-wide rollout are repetitive, there exists the ability to plan for their identification before ever walking into the conference room for your first team meeting. Having a clear approach that you're comfortable with will enable you to start off with confidence ( the mark of a leader.
There's another story about a New England codger, this one in Maine. It seems that a couple from New Hampshire were thinking of moving to Maine (they were probably tired of "not being able to get there from here.") They knew that in most small towns in New England, if you weren't born there you were considered to be "from away," even after twenty-five years of residency. The mother was expecting, and was determined not to have her child grow up being "from away." So when she went into labor, she had her husband drive her to the town in Maine and gave birth there. Later, after having moved and settled in, she was recounting the story to someone in the local general store. An old codger rocking in his chair outside the screen door overheard the story, and when the mother finished the story by expressing that since her son was born there he was a local, the man piped up with, "Ayuh, but a cat crawling into the oven to have her kittens doesn't make them muffins."
Replacing a successful, existing application with a well-written client-server application doesn't necessarily mean the new application will be successful, but after reading this book, my hopes are that you'll understand what ghosties and ghoulies stand in your way, and what it will take to be successful. And that the understanding of how to be successful will help you to move on to navigating through the fear, uncertainty, and doubt to determine what applications and approach have a chance at being successful after being implemented. Plan well; don't stumble when the paradigm shifts.
I hope you enjoy reading A Methodology for Developing and Deploying Internet and Intranet Solutions.
Jeff R. Greenberg Manager, Telecom Solutions Support Program HP Professional Services Organization Atlanta, Georgia May, 1996
"About this title" may belong to another edition of this title.
