Meet the experts: Lennart Frantzell demystifies the autonomic computing integration process

developerWorks: How did you get started in autonomic computing development?

Lennart Frantzell: I was educated in oriental philosophy, philology, and history. The step to IBM ® Advanced Technologies and autonomic computing may seem long, but it has actually been a natural progression. I started out in artificial intelligence and more specifically expert systems. How can we make computer systems smarter by encoding user knowledge in such a way that computers can process it? This is almost precisely the same concept as Common Base Events in autonomic computing. A lingua franca understood by the whole world, like the Latin of the Middle Ages. I then moved to implementing object-oriented systems and from there the progress to Java and eBusiness systems felt natural. A stint working with computer games was very nice as well.

Putting autonomic computing to work

LF: And I've been working for the last five years here in San Mateo at the IBM Innovation Center enabling IBM Business Partners on the latest IBM advanced technologies.

dW: How many centers are there?

LF: In 1995 there were two; now, ten years later there are 25 around the world.

dW: And what service do the centers provide?

LF: Focusing on our work here -we are here to get our Business Partners to market as quickly as possible on either IBM hardware or software or any combination of the two.

Our customers have already written their applications, but they haven't tested them with large numbers of users or in advanced configurations.

dW: How do you assist them?

LF: We help them design and configure a custom-built test bed and then help them to test their application on this topology, which usually is built around a three-tier [Java 2 Platform, Enterprise Edition] J2EE architecture.

dW: How do you help them?

LF: Well, we have the ability to generate large numbers of simulated Internet-users, and as the load increases we help the Business Partner diagnose any system breakages.

It's an interesting environment. We have advanced IT labs all over the world; we have the hardware and, of course, the software, and we have experience with the problems that developers may encounter in leading-edge Web-based installations.

So, we can get our Business Partners up and running on the right equipment, and this is, by the way, usually the very latest IBM high-end servers and, of course, software products.

dW: How do I as a potential partner approach you?

LF: They either come in through the PartnerWorld Industry Networks program or from our Web site .

dW: Do you ever approach potential partners?

LF: Yes we do. We have people out looking for new prospects and opportunities. For example, our cross-referral program within IBM often bears fruit.

Back to top

The centers: where customers and autonomic technologies get acquainted

dW: Let's talk about autonomic computing at the centers. How do you engage with your customers?

LF: It is actually a very effective variation of our standard way of working with our customers. Our Business Partners have applications that focus on various business areas and they want to add autonomic computing functionality to their applications. So, we work with them to add autonomic components from the IBM Autonomic Computing Toolkit to their applications.

dW: What's the process like?

LF: The Business Partner brings an application to the table. The first step in our engagement process is to look at the architecture of the application and determine how this architecture, and consequently, the Business Partner, can benefit from autonomic computing.

So, the first step is to do an architecture review to determine the best fit for autonomic computing concepts and to determine which IBM components from the IBM Autonomic Computing Toolkit will add value to the application.

dW: So it's after the architecture review that you make a recommendation to the client?

LF: Exactly. We produce a small architecture proposal.

dW: You propose alterations for their application?

LF: No. The Autonomic Computing Toolkit is very flexible and supportive; we never force the Business Partner to make changes to their application. That's a key point -if the Business Partner has to make changes to their application, the process would be too much of a stretch.

dW: There must be some problems to get the application and autonomic computing concepts together?

LF: We have adapters that we can deploy that work side-by-side with the Business Partner's application. The adapter architecture is elegant; the application can just continue to run as it is and we use the adapter to peek inside the application as it is running. Or to peek inside the Business Partner's customer's application.

dW: Any specifics on the adapters?

LF: Well, a good start is the Generic Log Adapter (GLA), which by now your readers probably know a lot about. The first thing is to look at the Business Partner's log files.

Now, keep in mind that usually it's the first time that the Business Partner developers have looked at these log files in quite a while. Often, almost instantly, we can point out to them information that shouldn't be there [in the log files] and information that is missing. Just by studying the log files, we can give the customer some very good datapoints about how well their application can play in the autonomic space.

After that, we'll do the conversion to Common Base Events here in the lab and then we teach the customer how they can do it themselves. But we can first do it quickly here in the lab; the output is a Generic Log Adapter file.

dW: Do you also provide jobsite testing on the customer's premises?

LF: We do all our testing here in the lab. We have the customer install the application here -we've got a comprehensive setup in the lab including extensive Virtual Private Network support -and once it is running here, then we hook up the Generic Log Adapter to it.

We can also simulate the Business Partner's applications if that makes more sense.

From there, we can go any number of ways.

dW: Such as?

LF: We can go to the Log Trace Analyzer (LTA), which gives an operator the chance to look at the log files and correlate them, or we can go to the Autonomic Management Engine (AME), which we really like to do because from there we can take actions such as writing resource models (which we typically begin by writing in Javascript and then we go into Java ™ programming). From there, of course, we can go anywhere; it's very flexible in that way.

dW: How do you go about choosing which teams to do the development?

LF: There are four of us who handle the major work for most cases, but we also pull in our colleagues in case we need access to technical or architecture support (for instance, if WebSphere is involved).

We can very quickly get advanced database or Pervasive Computing support, for instance, added. We have access to all the IBM technical support groups. It's all in the family.

dW: So writing the Resource Model is sort of the end of the process?

LF: Oh no. We write the Resource Model and then test it very carefully here. We'll induce an error that needs to be corrected. This is the Adaptive, or Level 4 of the autonomic computing model. We then define an action in the Resource Model. But the action can actually be directed anywhere. In integrations with the Tivoli Enterprise Console (TEC), for example, it is directed at the TEC. In other cases it can be directed back to the failing application.

There is another very important component to our services -documenting our efforts and results for the customer.

dW: Ah yes.

LF: We have a very nice graphics facility here so we come up with what I think is quite good documentation for the client. We ship the application back to the client who then in turn installs it and tests it out.

dW: How often have you had problems when the client tests the application?

LF: So far, the tests have worked on the first try. Part of the reason is that we use external adapters built on open standards so that our Business Partners don't have to make any coding changes to their applications.

The Business Partner then downloads the run times of the Generic Log Adapter, the Autonomic Management Engine, and the Log and Trace Analyzer from the IBM Autonomic Computing Toolkit Web site. It is important to note that at this point, they have taken the first step into autonomic computing.

Back to top

Turning the autonomic computing prototype into a working system

dW: And what's after the first step?

LF: Well, now the Business Partner actually has a system with an integrated autonomic computing component. So now the Business Partner needs to expand the prototype into something bigger.

dW: It seems that one of the important things you do is to prepare or "proof" them to thinking about autonomic concepts.

LF: It is. What we do is kind of a "speed start;" we explain how this works and then we're at hand to help them start working on their own. And usually they'll take specific information from their systems, apply it to this prototype, and continue to develop it on their own.

That is the general flow [of the process] of what we do.

dW: Does what they learn propagate forward?

LF: What will happen is that these Business Partners have their own customers, of course, and that's exciting because then we can get Mickey Nix and his team involved and undertake an engagement with the client and their customers. In fact, in his interview he talks about an engagement with Singlestep and LAN Solutions -the original conversion came out of this lab.

Back to top

Real-world examples of autonomic technologies in action

dW: What are some of the companies that you've worked with?

LF: There are quite a few. TechLabs is a New Jersey-based network-management company that has added autonomic computing to their portfolio here at the San Mateo center by natively generating Common Base Events directly from their J2EE application. We have actually published a joint whitepaper that shows what we did (see Resources ). This allows their DynaTrax switch to integrate with any other systems that "speak" Common Base Events, and gives them a flexibility and functionality that would be difficult to achieve in other ways. This is the power of using Common Base Events and open standards.

Another interesting joint project was with Network Physics, a Silicon Valley company also in the networking space. Here we added autonomic computing functionality to the Network Physics NP2000 network appliance by converting network data gathered by the NetworkPhysics' network appliance to Common Base Events and then collating and comparing that data to other network information using the Log and Trace Analyzer. We are now working on adding the Autonomic Management Engine to the mix.

dW: Do your customers go on to enable their customers?

LF: Let's talk about that.

In general, autonomic computing by itself is a "closed loop" scenario (we have the GLA, the CBE, and so on); however, in most large-scale implementations, you want to really go beyond that and tie into existing systems-management software. In this case, we integrate with Tivoli (especially the Tivoli Enterprise Console); a number of our engagements are focused on that. We're starting small with the proofs-of-concept and tying that in with the Tivoli suite of products. We're also "eating our own dog food" by using WebSphere and DB2.

That's how we're working with Sana Security, a Business Partner here in the Silicon Valley area. Their customers are often deployed with Tivoli, and we will add to that an autonomic computing facility, kind of a "bridge" if you will, a conduit between the Sana application and the Tivoli TEC, which fits in very nicely with the existing architecture.

That's one entry point we're employing. We're also using the Integrated Solutions Console a lot these days because it's nice for our clients since they can use it to monitor their own customers -so they can use it for customer support. I hadn't thought of that before. Rather than have their customers send them screenshots, they can just peek in on the action. We're using it here to see how Business Partners are proceeding with their integration plans.

Back to top

The challenge: thinking in terms of autonomic solutions

dW: Have you seen any challenges with the technology, any recurring problems, in your experiences?

LF: The autonomic computing learning curve is not insignificant. But the challenge is really more a matter of learning to think in a new way. It is actually easier to design an autonomic system than a manual system. We have learned a lot from object-oriented analysis here, and expanded on those concepts.

Once we have shown our Business Partners how to work with Common Base Events (as an example) -Common Base Events are relatively mature but it still takes some time to absorb the key concepts. So, what we do is teach our Business Partners a mini-course in how to get started. But once you begin to look at your own system from an autonomic point of view, the Common Base Event really falls into place. It is very similar to object-oriented analysis. It is a mindset rather than just learning a set of facts.

It's not just about getting our Business Partners to learn about our systems, but about getting them to learn more about their own systems.

Plus, most of them have small staffs, so the teaching effort has to come in small pieces that they can absorb quickly. This is something we're focusing on, and I think we're making really good progress.

dW: So you're focusing on a modular approach to teaching Business Partners?

LF: And we use patterns.

dW: I have to ask -so far, what autonomic computing component gets the most focus?

LF: Problem determination. I would say that 75 percent of all our engagements follows the PD scenario or variations of it. Although we're also seeing lots of interest in the Symptom Database.

And the persistence of Common Base Events across multiple systems is becoming more important because if you use autonomic computing as an integration point for the Business Partners, then they have to be persistent. Therefore, the Common Base Event is becoming the common glue.

Combining the Common Base Event with the Generic Log Adapter and the Log and Trace Analyzer, these systems are becoming important to our Business Partners; together, they allow them to build really exciting and efficient autonomic solutions.

Don't think of autonomic computing as a technology by itself, think of it as an enabling technology that works with other IBM technologies.

dW: What's the number one component that partners are most likely to choose to integrate?

LF: It's Common Base Events.

dW: Because everyone has a log file?

LF: Absolutely. It's a common, open standards way of encoding the states of your application so it can participate in advanced autonomic computing solutions. Even if a client doesn't have a log file, it's a language we all speak. It has performance advantages, and it makes integration tighter. So, when the client gets their head around Common Base Events, then they're on the track to using autonomic computing concepts.

We're getting more and more customers coming to us and telling us they want to generate Common Base Events (CBE) natively. Once they speak CBE, they not only have an integration point with our systems and their own systems, but also with other systems.

Oh, and they've also become extremely interested in the Symptom Database with pre-defined symptoms that are matched against possible solutions, all machine-readable, mainly because they haven't thought in those terms yet.

dW: Interaction with the symptom database is like teaching your system to learn how to manage itself.

LF: Yes. We've sort of turned application design on its head. There are all these log files that no one traditionally thought of as important -now we're taking them and showing Business Partners how important they are. They're the key to how the application was formed and predictors of how it will react.

By harnessing that information, we can make applications that will run more predictably; that, in turn, will cut out a lot of the manual operations. I am convinced that cutting out many of the manual operations will further add to the predictability of the application behavior.

Back to top

Autonomic computing opens the door to more

LF: One of the things to remember about the IBM Innovation Centers is that we are not just about autonomic computing -we also have lots of expertise in hardware and IBM middleware, so very often we get other experts involved, for example with WebSphere, with DB2, with experts in large-scale systems, external storage, mainframes, and the iSeries which I'm working on -so autonomic computing is not just a stand-alone technology, it is a entry-point into the entire IBM technology portfolio and beyond, to a new way of building complex self-managing business systems.

Resources

• Welcome to the 25 IBM Innovation Centers , designed to help IBM Business Partners migrate, test, and optimize their applications for an on demand world.
  
  
• See " Meet the experts: Mickey Nix on life in the trenches " (developerWorks, February 2005) to learn about the procedures and practices when implementing and deploying an autonomic computing solution for partners and customers.
  
  
• " Meet the experts: Kathryn Britton on autonomic computing's Integrated Solutions Console " (developerWorks, August 2004) demonstrates how the Integrated Solutions Console (part of the Autonomic Computing Toolkit) works, how you can preview it, and how you can participate in the development and use of this key autonomic computing technology.
  
  
• It goes without saying that the Autonomic Computing Toolkit is a necessary tool to achieve autonomic computing integration.
  
  
• See the center in action by visiting each of the companies mentioned in this article - TechLabs , Network Physics , and Sana Security -and reviewing their products.
  
  
• " Generate Common Base Events from within a Java application " (developerWorks, February 2005) demonstrates how the center helped TechLabs integrate the GLA's ability to produce and utilize CBEs into its DynaTraX Enterprise Management Solution.
  
  
• " Meet the experts: Why IBM is open sourcing Cloudscape as Derby " (developerWorks, October 2004) explains just that plus other strategic thinking on database technology -Cloudscape/Derby is the container for the autonomic computing symptoms database.
  
  
• Cloudscape/Derby is a pure, open source-based, 2-MB Java relational database management system that can be embedded in Java programs and used for online transaction processing.
  
  
• " Create a Correlation Engine for the Log and Trace Analyzer " (developerWorks, September 2004) show the interconnection of autonomic computing tools such as symptoms databases and the LTA, and teaches you how to make your system smarter when it comes to problem self-analysis.
  
  
• " Creating symptom databases to service J2EE applications in WebSphere Studio " (developerWorks, July 2004) shows you how to trace and diagnose run-time problems in user applications and how to analyze custom application traces using the LTA and Symptom Database Editor.
  
  
• The Symptom Database Editor is a part of the LTA that allows editing existing symptom databases or creating custom symptom databases, defining application-specific directives and solutions, or extending a product symptom database based on actual experience.
  
  

About the author

Comments

Back to top

Trademarks

Table of contents

• Putting autonomic computing to work
• The centers: where customers and autonomic technologies get acquainted
• Turning the autonomic computing prototype into a working system
• Real-world examples of autonomic technologies in action
• The challenge: thinking in terms of autonomic solutions
• Autonomic computing opens the door to more
• Resources
• About the author
• Comments