Kathryn Britton is a Senior Technical Staff Member for IBM in Research Triangle Park, North Carolina, and has been with IBM for more than 20 years. Over the last several years, she has been involved in a number of Web application, Web presentation, and networking projects, and she brings all this experience to her new role as the lead architect for IBM's Integrated Solutions Console project.

developerWorks: How would you describe autonomic computing technology to someone who has never heard the term before?

Kathryn Britton: I'm not trying to explain it to my parents?

dW: No, more like, to someone from the developerWorks audience; someone who is technologically astute, but who might not have heard of it before. Because, it's all pretty new, isn't it?

KB: Yes. Well, autonomic computing is an initiative to reduce the growing systems management costs by making it possible for systems to manage themselves to a certain degree. The metaphor is the autonomic nervous system in the body; you don't think to breathe. You don't have a thought that says, "OK, I've got to take a breath." Your body just takes care of it without you having to think about it. And the only times you do have to think about it are when, for example, you run too fast and get out of breath, or if you're choking or something like that. So, the idea with autonomic computing is to make the systems themselves able to take care of the daily ups and downs without requiring a human to be involved, because it is the human costs that keep going up. And they keep going up out of proportion to the other expenses of IT systems.

There is a mnemonic that people working on autonomic computing use, called self-CHOP, where the C stands for configuration. You want to have systems that can configure themselves to operate in a known environment. Then, there's self-healing; if something goes wrong the system can detect it and fix it, similar to your immune system. There's also self-optimization, which is being able to detect that you're using resources suboptimally and fix it. Finally, there's self-protection to detect any security threats and to be able to deal with them without human intervention.

The last one, self-protection, gives you a comparison that might resonate with people. Think of all the time in a company that is spent sending e-mail saying, "update Windows™ to be at the latest service level because there's now a patch available for a Windows vulnerability," or "make sure you run your antivirus," or "run it again, because a new threat has appeared." Some of this we're already making autonomic in the sense that there's Live Update that detects when you need to update something on your system. People usually have their virus system set up to run automatically at given times. But, you could make it more autonomic by having the detection of the update then cause an immediate scan, for example.

dW: What kind of impact will Autonomic computing have on end users, the kind that are doing something maybe more complicated than ordering something from a catalog, or more meaningful than just surfing the Internet -- but they're not IT people? Will they even know that this is happening in the industry?

KB: It could reduce the amount of down time they experience. It could make certain things like the security management take care of itself, as opposed to their having to keep worrying about it, on the very low level that we tend to worry about it today. It could potentially make their working environment richer, because instead of spending so much investment on maintaining and managing the systems, there would be more time available for building new applications or for integrating things, which would make their working lives run smoother. So, it's more a matter of autonomic tends to affect the quality of service they get -- not affect what's available to them in terms of applications and so on, but to affect how well that service is provided, how well it performs, how reliable it is, and so on.

dW: How did you get involved in autonomic computing?

KB: I got involved in autonomic computing in a rather odd way. I am the architect for a project called the Integrated Solutions Console (ISC), which is completely human facing. In other words, there is no assumption with a console that we are making it automatically do some of the work that humans do today. Instead, we are saying OK, let's take the things that humans have to do, where humans have to interface with the systems, and let's make those better. Let's fix some of the problems that we have created for customers in terms of trying to manage those systems once they get them all put together.

I heard someone describe a visit to a hosting service where they saw that there were approximately seven or eight different consoles that the operational staff were moving between in order to keep things running or to detect when something was wrong. You might detect or see a problem in one console, go to another in order to fix one part of it, and go to another to fix another part of it. So, the purpose of the Integrated Solutions Console is to bring together all the operations, system admin, and management pieces into one console and then, even further, make it so that the pieces work well together to eliminate the redundancy. Therefore, you can use the same habits -- you know when you move back and forth between two systems, you have habits that you've developed from the one that's the most familiar to you, and when you go to the other one you keep making mistakes?

dW: I know exactly what you mean. I keep accidentally closing my Web browser window because I'm doing control-W to search, instead of control-F.

KB: Exactly. So what we would like to do is to reduce the amount of time that humans spend learning how to deal with all these different consoles. We would like to use this Integrated Solutions Console as a way of starting to think in more ambitious terms about putting together the human tasks in such a way that we can support the humans who are doing them, instead of focusing just on the products that these consoles represent. So to work backward from the customers instead of forward from the products, if you see what I mean. So then the question is, and I've been asked this many times, "Why is this in autonomic computing?"

Well, I can answer that at the metaphorical level, which is to say, all right, even though you don't have to think about every breath, occasionally you want to be able to check and see if you are still breathing. People do sometimes, for example, check to see at what rate they are breathing. The same is true of your heart and your blood pressure. You don't maintain your blood pressure, but you do sometimes want to check, "OK, is my blood pressure in the right range? And if it isn't, what do I want to do about it?"

If you think of it in the metaphorical terms, we're not, with autonomic computing, taking humans out of the equation. Instead, what we are trying to do is to create a partnership between the systems themselves and the humans that both need them and manage them. Therefore, the things that systems can do well, they do, and the things that humans are needed for, the humans are there. You can think of the Integrated Solutions Console as being the window into autonomic computing; it's how you can see what is going on in an autonomic computing system. The integration that it helps create is something that makes it easier to do autonomic computing.

dW: The Integrated Solutions Console, if I'm not mistaken, presents a common interface to most of the major products that IBM offers -- WebSphere™, DB2™, Tivoli™...

KB: It doesn't yet, but including these products will be important for integration. It is going to be rolling out over months and years. It has been a very interesting project in terms of how much of a joint effort it has been between groups across IBM. I mean, there has been very, very close cooperation and collaboration between Tivoli and Systems Group, between Lotus and WebSphere, between WebSphere and DB2, and between Rational and all these groups. In other words, the Integrated Solutions Console has been one way of pulling a lot of different, independent groups together. Now, it isn't always the case that groups are interested in coming together on a shared technology like this. But, I think there's a recognition that it is inefficient to have each group spend time on console infrastructure. I think that it would be far better to concentrate on the usability of content, the plug-ins that go into the console infrastructure, than on the console infrastructure itself across every different group.

dW: Oh, so each of the groups, to take advantage of the console, basically just has to create plug-ins?

KB: Exactly.

dW: Well, that sounds much simpler and more efficient than what I had been imagining was behind the scenes!

KB: The technology the people are using is portal technology. They build portlets, which are composable units of user interface. Right now, they need to use the IBM proprietary portlet API, but we are moving quickly to provide the JSR168 API that's coming out of the Java community process.

dW: Is that open standards/open source?

KB: It's not open source, but it is a form of industry standard. So the advantage of doing this is ... there are multiple things you have to do when you develop a user interface: you've got to develop what it looks like, and then you have to connect it to the things that it controls or pulls information out of. So, what we're doing is moving people toward using standard technology for building the visual part. Instead of having to have a special set of tools for a proprietary framework, we're making it so people can use standard portal and application server tools. This means that instead of every product having to worry about, "How am I going to manage the security issues? How am I going to make sure that only people who should be in the console can get to it? How do I make sure that people only see what they are supposed to see?," the framework can take that over. They can focus on the meat of their own domain. They can use their domain expertise instead of having to worry about all of these surrounding questions.

dW: So the Integrated Solutions Console is basically a framework?

KB: The Integrated Solutions Console is a framework.

dW: And it's based on Eclipse?

KB: No, it's based on portal technology; people build their content as portlets and package them up into packages that can then be deployed to the Integrated Solutions Console framework, which uses some WebSphere portal technology. So, the portlets can use the Integrated Solutions Console directly, they can use portal APIs, and they can use WebSphere Application Server APIs to get the job done. The administrators, the people who are going to be using the Integrated Solutions Console, just access it from their browsers. They don't have to have anything installed on their workstations. All of the systems management capabilities that they are using through the console are maintained on a centralized server or two, and then they get to see it in their browsers. So, I guess, the ISC itself is a framework, but it's also a sort of a rallying point; a place that, because they are all going to plug their content into the same framework, groups across IBM are, therefore, working together on the outcome.

What has been unexpected to me is how much of a will there is in the community to do this. And, what's been exciting to me is working with so many different people who have so many different points of view, and yet are able to help create collaboration out of all those different points of view.

dW: Ultimately, the ISC would manage also non-IBM products; is that right?

KB: Yes. In fact, I believe that the Integrated Solutions Console is already available as part of the Autonomic Computing toolkit, which can be downloaded from developerWorks.

In fact, that is an exciting aspect of the ISC, that customers or business partners, systems integrators, and so on can look at what's available in the ISC from their various IBM products, and then decide, "But I want to also be able to control these non-IBM resources. I want to control these application-level resources that are built on top of the IBM products. I want to be able to control other things." They can build their own portlets using standard portlet technology, and then we've got a tool for packaging them up and creating page layouts. They can then deploy them in the ISC, and they just appear along with everything else that is there.

And one comment I'd like to make about plugging things in. A couple of the areas where I get excited about the ISC -- and this is the promise that comes with the integration part of the name -- is that product groups in IBM can put together what they believe the right content is for various functions. They can put together a set of portlets on a page, and they can arrange them the way they think customers need them.

But, we know that we don't get it right for every customer, every time. So what the Integrated Solutions Console provides with its tool is the ability for customers to do some systems analysis; you know, watch their operators and see how they actually perform tasks and see that, oh, operators keep having to switch back and forth between these two pages to get a particular job done. So the customer can do the systems analysis, they can have somebody watch and see how this person really does carry out the job? And then they can rearrange the portlets [and] they can put them together in new pages that they create themselves. I think of it in the way that it makes it possible for customers, or consultants for customers, to be able to do some efficiency analysis of the way their operators work, and to rearrange the content to match their own operations.

dW: You mentioned JavaServer Pages (JSP) technology and WebSphere Application Server -- are existing standards like these enough to meet the ISC's needs, or are there new standards that you think you are going to be needing?

KB: Well, some of the other standards-based work that's going on in autonomic computing is important, because we'd like to make it possible for people to build these visual elements and have them be able to operate on more than one resource of a given type. We've had experiences where groups from [IBM] Software Group and Systems Group have gotten together and divided the work of writing the set of portlets they both need for similar kinds of functions. What they found was that they needed to have an intermediate layer in between the user interface and the systems elements being managed, because the native interfaces for the system elements touched by one portlet they were monitoring were different. So to the degree that these resource management APIs can be made standard, that will make it a lot easier and more efficient to build "view elements" that can be reused.

dW: Now, is all of this work within IBM internally basically laying the groundwork for opening ISC up to other industries more, once it's more established -- or could somebody from outside of IBM be working as closely with you already at this early stage?

KB: Oh, I think that people could start working with us right now.

dW: And how can they do that? Who can they contact, or what newsgroups should they join?

KB: There is a person, Joshua Hauser, who is involved with business partners.

What is exciting to me about this possibility of business partners plugging stuff in is not just that their stuff would appear in the same console, but that the relationships between other non-IBM products, services, and so on -- and the IBM products that they connect with -- can then be represented in the console by work between the two groups. So it isn't just, you put your plug-ins in; it's more, you put your plug-ins in, but at the same time we'll provide ways for you to integrate with what's already there, so that all the products that make up the system -- yours, IBM's, other vendor's -- are manageable as a unit, as opposed to just separate elements.

dW: And is the Integrated Solutions Console already being used or tested by customers?

KB: It's in beta with the Integrated Runtime, and it's part of the announced Virtualization Engine and Tivoli Federated Identity Manager products.

dW: As a developer, what can I do to incorporate the self-CHOP principles into my program? Can I just add a layer, or do I actually have to rewrite the whole application?

KB: One of the guiding principles behind the autonomic computing effort is that we're not going to be able to require everybody to rewrite everything. So, we have to make it possible for people to get to autonomic systems from where they are, as opposed to having to start over. There's a structure in autonomic; I don't know whether you have seen it - the MAPE Loop, [which stands for] Monitor, Analyze, Plan, and Execute.

dW: Actually, no - I haven't seen that yet. I have to admit that this is all pretty new to me...

KB: Well, that's something that ... you will hear about. There's a concept in autonomic computing in which you have autonomic managers and touchpoints, which are the interfaces that autonomic managers use to access the resources that they manage. By resource, I mean something that's very broadly defined; any managed element of the system. What autonomic computing is bringing is what we call a sensor and effector interface. Sensor is how you get information out of the resource, and effector is how you change its operating status or parameters. So basically, instead of trying to say to every resource, you've got to build all of this autonomic knowledge into yourself -- instead, we tell the resources to give us a sensor interface so that we can pull all kinds of information out of you, and here's the kind of information we need. Give us an effector interface, so that we can make certain changes to you, and you get to decide what those changes are. Then, separately, we will build autonomic managers that can use those sensors and effectors to figure out what should happen. The idea is to take existing products and ask them to add these interfaces called touchpoints. And other than that, all of the operating by policy, managing the MAPE Loop, and so on, is new function that is added in the form of autonomic managers. And autonomic managers can operate with multiple kinds of resources.

dW: I saw the online PDF of the your presentation, "Tight Console Integration with Loose Development Integration: Technical and Organizational Support" which you gave at the Conference on the Human Impact and Application of Autonomic Computing Systems (CHIACS2) in New York in April. One thing that really struck me was when you mentioned the importance of the command line to system administrators?

KB: Here's how I would put it: there are some tasks for which a graphical user interface is appropriate, but there are also tasks where it's not. Let me give you an example of one where it's not. If you have to do the same job over and over and over again, if you had to do the same thing to seventeen different systems, you wouldn't want to have to go through the same set of GUI panels, particularly if it were a fairly complex operation. What you'd really like to do is to get it set up, and try it out, maybe on a test system, and then, once you know that you've got it right, you can run it on all the rest of them without having to go through those steps. So, anything that's repetitive, anything that you want to rehearse and then make sure that you don't make any changes after it's been put together, that is, you want to make sure that there's no chance for human error in the actual production stage, those are things for which people realistically use command lines a lot. What we would like to do over time is to create a partnership between the command-line approach and the GUI approach so, for example, you could use the GUI to watch the progress of a command-line operation. Or you could have command-line operations that stop at certain points and let users interact with them to fill in information and then let them resume. Or maybe even have GUIs that help create the command-line user interfaces. So we'd like to get to the point where these two are both accepted forms of user interfaces, and we make it easier for people to use them, and for people to use them together.

dW: So this is being built in to the ISC, that they will be working together in that way?

KB: It's certainly one of the design concepts.

dW: Do you see yourself still working on this three years from now -- or will it be a solved problem by then?

KB: Oh, no no no. It's a problem that will go on and on! I can see myself still working on it in three years, probably on higher and higher levels of the integration problem, because that is what excites me, the question of how do you bring all these separately implemented system elements together into a solution package, into a system, and make the whole thing appear as a system to customers, as opposed to a bunch of separate parts with different personalities, which is what we often have today.

I have a vision that the Integrated Solutions Console can take us much further along the path of integration than just putting all the content together in one place. I have a vision that we can match customer business processes -- we can match the IT service flows that provide services to business processes -- that we can match the way the customer thinks about them by exploiting the ISC flexibility, including the ability to recombine systems management portlets in different ways. Also by providing certain sequence guidance, so that if you have to do a certain task that involves touching multiple products, then we help you move through it in the right order; we can help guide you through things that today people have trouble with. I see the Integrated Solutions Console as being able to provide integration at a number of different levels. What I get most excited about right now is the possibility of bringing together the spirit of cooperation and collaboration that I'm experiencing across IBM and focusing it on making the integration of these functions in a user interface be really top-notch.

dW: Thank you very much for agreeing to do the interview with us.

KB: Thank you, I enjoyed the experience.

Resources

• Download the Autonomic Computing Toolkit from developerWorks. You will also be interested in IBM's Developer resources for an on demand world, which offers a wealth of resources.
  
  
• You can experience the ISC for yourself; the Integrated Solutions Console is a part of the Autonomic Computing Toolkit.
  
  
• The ISC is also available in the latest beta release of the IBM Integrated Runtime and in the recently announced Virtualization Engine.
  
  
• Read about self-CHOP, the MAPE Loop, and more in An autonomic computing roadmap and Understand the autonomic manager concept (developerWorks, February 2004). See also ABCs of the Autonomic Computing Toolkit: A beginner's guide (developerWorks, November 2004).
  
  
• The Create an administrative suite tutorial (developerWorks, February 2004) describes how to run the ISC, and reviews the process for creating your own ISC component.
  
  
• Learn the ins and outs of the Integrated Solutions Console by implementing an ISC-based help system. Help in the Integrated Solutions Console (developerWorks, February 2004) and Enable a help system within the Integrated Solutions Console (developerWorks, May 2004) will get you started.
  
  
• Kathryn's presentation, "Tight Console Integration with Loose Development Integration: Technical and Organizational Support" (in PDF format) was given at the Conference on the Human Impact and Application of Autonomic Computing Systems (CHIACS2) in New York in April 2004. You can view the other presentations online as well.
  
  
• IBM Systems Journal has a collection of autonomic computing articles, as does IBM Research.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments