The Art and Orchestration of ALM
Borland CTO discusses Borland's application lifecycle management strategy.
by Carolyn Wong

JavaOne, June 28, 2004

Application lifecycle management (ALM) extends development to operations management. In this interview with FTPOnline, Borland CTO Patrick Kerpan talks about how Borland's ALM strategy involves embedded integration and how the company's JavaOne announcements come into play.

	Borland CTO Patrick Kerpan spoke about tackling complex enterprise applications at JavaOne on Monday.

FTPOnline: CTO is a relatively new position for you. What are your priorities or directions in that job?

Patrick Kerpan: I've been with Borland for four years, just leaving the role of general manager of our development services group that makes the StarTeam configuration and change management system and the CaliberRM requirements management system. I was one of the people within Borland involved with identifying, acquiring, and integrating the StarBase company from which those products came. Prior to that, I spent most of my career in the world of derivatives technology for large global banks. So I came from large-scale, enterprise transaction processing systems, which clearly creates a bias toward my view of how software development is becoming like that as well.

We believe we're now entering the era of the industrialization of software development where people want to put in place factory-style processes to build, deploy, and manage their enterprise software applications. This ties into what's going on at JavaOne and the state of Java, if you look back at Java's past. In a relatively short period of time, Java's grown from a community of early adopters into an enterprise computing platform of the likes we've never really seen before. The Java tent is just so big now. Borland is focusing on application lifecycle management.

Application Lifecycle Management
FTPOnline: Borland went on a spree to fill out all the pieces of its ALM strategy. Can you define some of your goals within the ALM realm? How well-integrated are the tools? And can you discuss some of the specific components of your ALM strategy, such as requirements, modeling, optimization, profiling, and development management? How is Borland addressing them?

Patrick Kerpan: As a broad objective, you can look at it as art and orchestration or musicians and orchestration. Borland has a history of providing innovative tools for individual developers, and we have to continue doing that; there's still a lot of art here. If we're using the music metaphor, we still need to provide them with the musical instruments that allow them to be the fabulous artists they are.

That said, we are now in an era with a need for unparalleled orchestration. Some Java developers, modelers, QA people, and business analysts are part of a massive symphony, or a huge marching band, or a four-man grunge band. And we really need to help them orchestrate their work at the level that's appropriate for their group. At a high level, we want to keep the art but enable the orchestration.

When we made the acquisitions of Together and StarBase, people said, "What are you going to do?" We said "integration." To some degree, we got a ho-hum response of "oh, everyone says 'integration.'" But look at what we call "embedded integration," which is pieces of one application lifecycle capability showing up inside other applications within the application lifecycle—bits of requirements data showing up inside the modeling tool; bits of the testing tool showing up inside the requirements tool; bits of change management, requirements, and modeling showing up inside your coding tool. We call that embedded integration. That's the level of integration we make available to the Java developer today, whether on top of the JBuilder platform or on top of the Eclipse platform. In terms of where we came from, we've made tremendous strides in the last 15 months in embedded integration. We define integration as touch-point, which is what most of the industry has today: You have Tool A and from the menu of Tool A, you can launch Tool B.

Once you have embedded integration that involves a development environment where change requests, models, configuration information, and requirements all show up in one place and are always available, your customers start discovering interactions they would like in that type of environment. We then call that "synergistic integration." You can't get to synergistic integration until you've done a solid job of embedded integration. We have the foundation now. We're working on how we can make this integrated environment even better.

FTPOnline: Borland's ALM was limited to the development cycle, not including operations management and what happens after development. How has that changed with introductions such as Borland Development Op-Center that now seem to fill the gap between development and deployment? How do you see operational concerns impacting the development cycle?

Patrick Kerpan: As we talk about the application lifecycle framework, historically when you see "define, design, develop, test, deploy," they sit in a linear row across a page. That visual image tells you—and even worse, your management—that the application lifecycle has maybe four handoffs in it. If there are only four handoffs, management says, "why do you guys whine so much about needing better tools, better equipment, and more time?"

So that's what we've been integrating. We pulled that image into a circle surrounding "manage." Every facet of the application lifecycle, like pieces of a pie, touches one another. That visualization is the why the world works. My requirements need to be connected to my test cases. My change requests need to be connected to my code. My models and my code are almost the same thing at this point, so they clearly need to be well-linked to each other.

Within that picture, you now have a natural flow from the things we traditionally do with development—the "manage" is the orchestration of development at its simplest form. Then you bring in modeling, requirements, and change requests, and you get pressure from customers to fill in the other spaces.

We started with unit testing for the developer with Optimizeit Suite. One of our announcements at JavaOne is that we're now making Optimizeit Suite available to Java developers on the Macintosh. Optimizeit Suite is for developer use in the creation of the code for code coverage, profiling, thread management, and thread review. We found that people were trying to use that application in pre-deployment mode or even in an emergency in a diagnostic mode in the datacenter. It was written with the developer in mind. You're going from threads, and you click on something in a thread to get to the line of code where you have a potential thread lock.

That doesn't work for datacenter folks; that doesn't work for pre-deployment. So out of that ServerTrace was born, and we're announcing ServerTrace 3 at JavaOne. Prior to version 3, the product was more for pre-deployment. If you're a pre-deployment person, you're in the staging area and the developers have just handed you a J2EE system you must roll out. You need to know what's going to happen in the next six to eight weeks, so you fire up ServerTrace and you start to get a sense of the performance profile of this J2EE system—not just a J2EE application, but a J2EE system. ServerTrace speaks in the semantics of the J2EE system, so the pre-deployment people can see not only the line of code in the JDBC driver where the problem is, but they also see the SQL statement that's causing the performance problem. It takes it up a level. They see the offending EJB component, not the line of code somewhere deep within a getter or setter method.

In the datacenter, when ServerTrace 3 in hibernate mode identifies a problem, you can use your normal enterprise monitoring tools, but you now get good ServerTrace information in the semantics of J2EE about what's happening in the environment. The other thing relevant now to datacenter teams that we've added is support for service-oriented architectures [SOAs]. Once your J2EE infrastructure is potentially calling outside your area of control—the partner-based Web services or services outside your datacenter—you need some visualization about what's going on in this distributed application. There's monitoring, reviewing, and filtering of the information about the performance of the entire J2EE system, including knowledge of how to watch the Web services. The ServerTrace 3 monitoring solution allows the datacenter staff and the pre-deployment staff to look at things from a J2EE semantic level—from the datacenter topology level—but the low level of information that finally makes its way back to development is of the type necessary for them to do their work.

More Emphasis on Integration
FTPOnline: How does the integration you mention fit in?

Patrick Kerpan: ServerTrace 3 wouldn't be complete without integration. For example, with the information you get from ServerTrace 3, you can raise special types of change requests in your StarTeam system and make use of StarTeam's workflow to route the full trace information back to the developers involved. It's been interesting that what started as unit testing developer-level application performance has now evolved into ServerTrace 3, which goes one more step to provide datacenter capabilities. The key features are on-demand diagnostics, ALM integration, support for Web services, and the mapping of datacenter language/J2EE semantics to the language the developer understands.

We've made some announcements about our testing partners such as Mercury Interactive, Segue Software, and for JavaOne a new partnership with Empirix; so now with those vendors' products, you can do load testing with ServerTrace. With every facet of our ALM product, we've been updating and integrating with partners like that.

FTPOnline: How do enterprises manage all the new technologies and processes these integrations involve?

Patrick Kerpan: With integration you keep the art but allow the orchestration. Look at the size of the Java tent now and what's coming with JavaServer Faces [JSF]; all the ideas around model-driven architecture, whether strictly OMG MDA or beyond; the work that's already happened with SOA; and the amount of JSRs hitting the JCP at any given time. How do customers know when it's real? The Java platform has reached such a depth of capability that in some ways it seems like things are coming as fast or even faster than they did during the dot-com boom. But these things are real or are going to be real. It's clear that software development has evolved in one dimension to be a team issue in how you orchestrate and make a team efficient, but even within the personal productivity of an individual developer, what's the right tool for the right job?

Enterprises must adopt a portfolio management approach even for developer productivity. When do you use JSF? When do you use MDA? When do you use Swing? When do you use SOA principles? We view Borland's role through our products such as JBuilder and others to rationalize these new feature sets into one, well-understood development environment, so that making use of JSF and MDA becomes incremental learning and training. How many boutiques are showing up saying, "buy our standalone JSF tool, buy our standalone MDA solution." Can a company realistically afford to have separate tools for each of these? One of our themes at JavaOne is "the right Java, whatever the gig." Our priority is: How do we help the Java developer and the Java organization effectively bring to market these new and exciting Java capabilities at the moment they're capable of being real? We're not going to come out with a standalone JSF tool or a standalone MDA tool.

Community
FTPOnline: What was behind your decision not to join the Java Tools Community? Any changes here?

Patrick Kerpan: Yes, one of the other announcements we're making at JavaOne is that Borland is joining the Java Tools Community. As we've been looking at the technologies coming through the Java Community Process [JCP] such as JSF, we're seeing a lot of implementations of JSF, and we're concerned about the lack of interoperability at design time. If I make some elements in one tool, I can't use them in another tool, which affects the users. A lack of consciousness to follow toolability standards is more of a vendor-centric issue, and it's in the best interest of the leading vendors in this space to keep an eye on toolability and how we interoperate at that level, so we can design-time our platform interoperability for our customers. Otherwise we're attempting to lock them into one solution.

FTPOnline: Why didn't you join the JTC originally?

Patrick Kerpan: It's now made clear that the JTC is not a competing mechanism to the JCP. It's a liaison mechanism driven by the kind of customer engagement the main members have. We get clear messages in all forms from our customers about how these tools must work together. Because when you're dealing with such large enterprises, they probably have each of our tools there. Again, how do you help them manage that portfolio? How do we help them orchestrate it?

FTPOnline: Are you spearheading any initiatives with the JCP?

Patrick Kerpan: We're still one of the leading members. The JCP has a specific set of activities, patterns, and processes it follows, and Borland has been an executive member for the past several years. Now it's clear how the JTC can be a forum for the vendors to have some discussion and liaise into the JCP with more of a collective voice rather than all these issues hitting the JCP separately, and this gives us a place to work through some of the complexities.

Changing Tools Market
FTPOnline: Eclipse is a challenge to Borland. How do you balance your involvement and competition with Eclipse?

Patrick Kerpan: We get back to the idea of how big the Java platform has become and how Borland is committed to helping Java organizations be successful. If you look at base Eclipse, it's an IDE framework comparable to what we internally call at Borland, PrimeTime [OpenTools API]; JBuilder is built on top of PrimeTime. We're focusing on ALM for Java, not just ALM for JBuilder. So the embedded integration tools I've mentioned all exist for the Eclipse platform as well. We believe we have the leading ALM solution for Eclipse today. When you start dealing with large enterprise customers that have Team A with 500 people using JBuilder and Team B that has a couple more hundred using Eclipse, how are you going to orchestrate that? That's what Borland is committed to. We don't just talk about freedom of choice. We deliver freedom of choice in our products.

Ease of Development
FTPOnline: Borland has a history of supporting ease of development with Delphi. How will you address that need on the Java side? How do you address the corporate developer opportunity?

Patrick Kerpan: The corporate developer and the more independent developer both need tremendous personal productivity tools. The difference is the scale of orchestration necessary in the enterprise environment, especially if you look at large industry trends right now: offshoring and pursuit of CMMI certification that require a level of orchestration the independent developer doesn't have to be a part of. You want to enable an organization to pursue business agendas that are technology driven without completely turning the world of the individual developer within an organization upside down. You need an orchestration framework with embedded integrations with requirements and test cases.

FTPOnline: We keep hearing from Sun Microsystems, BEA, and others about expanding the development market into the tens of millions. Since Borland is one of the few companies exclusively focused on developers, what is your view of that?

Patrick Kerpan: You never lose sight of the unique developer. Because every company in its own way is now a software company, and no matter how quickly we get good at some of the drag-and-drop facilities, developers still drive the business. You still have to understand a lot about the platform you're working with, such as J2EE, and you need to have the abstractions hidden from you at some times and perfectly visible at other times. Borland has a track record over the past 20 years as one of the companies that has raised the bar of abstraction time and time again. I think you'll see us as a leader in JSF and SOA, but we'll do it when the moment is right—when the tools are real and made available to customers in a package so that they can train their people and have design-time interoperability and a fair amount of confidence that the vendors on the back end are doing their work as well.

We don't think one size fits all. And vendors have to look at that. As a result, customers must examine their tool portfolios because J2EE has such breadth that you will want to take advantage of the different capabilities it has to offer depending on the type of system you want to build. You must consider the financial return of the system, the risk of the system, the time-to-market of the system, and the number of users of the system.

About the Author
Carolyn Wong is editor of FTPOnline.