Sponsored Link •
Frank Sommers: In the 1980s and early 1990s, many American corporations realized the need to reengineer their operations to better respond to global competition. With networked services becoming strategic to many organizations, and networks becoming overly complex, do you think the time has come to think about reengineering the corporate MIS infrastructure as well? Do you see Jini playing a role in this arena?
Jim Waldo: There is a tremendous amount of talent in MIS departments around the world being used for fairly trivial tasks. Troubleshooting and crisis management are not terribly enjoyable, nor challenging. They are challenging only in the sense that they are constant and you have to do it. It's like being in the line of fire all the time. People in these MIS organizations have the talent to figure out ways in which companies can use their computational resources more effectively. However, with the existing infrastructure, they don't have the time to do the thinking that's required to accomplish that.
I think Jini could help reengineer MIS infrastructures. Rather than being a reactive organization, where the MIS manager's goal is to keep things from falling into total chaos, using Jini, the organization can become more proactive, where the MIS manager's goal is to plan for the strategic network upgrade over time to meet user needs. Managers will have the time to think about what is needed, instead of reacting to their day-to-day problems. MIS management becomes a very different job; it's not troubleshooting, it's planning. Using Jini, managers can concentrate on things like service quality. They can manage the change and do long-range planning. They can focus on what they will need a year from now rather than keeping what they have together with the bailing wire and chewing gum they currently use.
Frank Sommers: If an MIS manager decides he's ready to make this paradigm shift, how would you suggest he go about it? What would be the first steps?
Jim Waldo: First, begin to understand what Jini really is and how a Jini network works. Many books and articles can help you in that area.
Next, embrace Java as fully as you can. Many MIS managers have already done that, but they especially need to realize that Java and the object mobility it provides is a key entry into Jini.
Beyond that, start some pilot projects to see how this could work. Pick two or three problem projects, services that are necessary but difficult to maintain, or services users demand but you're not quite sure how to create. Create those services in a Jini-enabled fashion, and then experiment with how you can change them over time. The nice thing about Jini is you don't have to convert everything to Jini all at once. You can convert just a small area, a portion of the enterprise, or just some applications used in the enterprise. You can ease into it as you gain more experience.
Frank Sommers: Are you aware of similar technologies today that MIS managers could choose if they want such a different paradigm for their management information systems?
Jim Waldo: Actually, I don't think so. Jini differs from most other technologies in that it takes the network seriously as an entity in itself. It's not a way to build things that get connected by the network, but a way to build networks of connected things. It makes the network an entity that always runs, and may have parts changing as it runs.
It is a different approach from most distributed systems, which say that the network is merely a data exchange mechanism between the things you build, so you build these components that get connected by these wires, as opposed to building a system that is the network.
The only people who think in the terms that we in the Jini world think of the network are the telcos (telephone companies), where the network is very much an entity, separate from all network-connected pieces.
Frank Sommers: And telco networks are typically very reliable...
Jim Waldo: The telcos are reliable because the network is the entity guaranteed to be there all the time. Things change all over the place in the telephone network, but the changes never bring the telephone network down. That's how we have to start thinking of our enterprise networks, our home networks, our personal networks, our ubiquitous networks. We rely on the network, not the things connected by the network.
During his JavaOne 2001 keynote, James Gosling made an interesting point. He said we talk a lot about network services and people translate that into servers, but services aren't servers, even though they may run on a server. The service lives on the network and if its location changes on the network, it shouldn't matter to the clients because they access the service from the network, not from an entity connected on the network.
The network provides the service, not the things on the network. You don't dial through a particular switch on the telephone network, even though the switch enables that to work. Instead, you just use a telephone network to call somebody on another telephone. We must think of our corporate computational networks in that same way.