email article printer friendly

Diablo Lights Up Shared Services
The latest WebLogic application server could hook up your enterprise in ways you'd only dreamed about. Mark Carges, BEA's CTO, reveals what to expect—and what to hope for
by Steve Gillmor

February 24, 2005

Just a few months after Mark Carges started his new job as BEA's CTO, Diablo—the 9.0 version of the WebLogic application server—was released. Diablo is described by BEA as "the cornerstone of its upcoming WebLogic Platform 9.0" that will offer the next generation of integrated components for connecting disparate systems and running mission-critical applications. Take a look at what Carges has to say about some of the details behind the technology in addition to meeting customers' needs in terms of SOAs, shared services, governance and organization models, and more in this exclusive interview with WebLogic Pro.

WebLogic Pro: You've talked recently about the issue of services and what the concept of shared services implies—a macro approach. Maybe you could start by describing some of the things you've personally been working on—at BEA and before that.

Mark Carges: Before BEA, I worked at Novell, where my background was all Tuxedo. I helped create it about 20 years ago when I worked at Bell Labs. It was spun out with UNIX System Labs, then again to Novell. When Novell wanted to sell it off again in 1996, BEA decided to take it, and that's when I joined BEA, as part of the Tuxedo acquisition—although I haven't been doing much with Tuxedo since then. I've mostly been doing new work product introductions and digesting some of the acquisitions we've made and that our portal group made. The last two years I was in sales and I ran our global account program—basically our top 20 worldwide customers working with the sales team—and then back in August I came into the technology side in this role.

WebLogic Pro: We'd like to try and connect the dots between the role of middleware when you are on the inventing side, and where it is today in terms of the overall service-oriented architecture.

Carges: In my experiences, I got a very good sense of how customers think about adopting SOA and the kind of things we have to help them do. Some of our customers are not technology oriented. For some of them, technology is only a small part of what they need to wrestle with to move to SOA. These people did not have to be convinced about the merits of it. They know the problems of SOA because they are the same problems they have had for many, many years—decades in fact. They have tried to do this before, but technologies are now at a point where they can do it. But when they tried to do it, they ran into all sorts of other issues like governance and an insufficient organizational model.

CIOs often ask, "If I am going to share, who pays?" Let's try an example. Let's say we've got three organizations, and I have a service that I'm going to offer. I'm the services organization, you're the sales organization, and over there is the marketing organization. I might say, "I have this service that the rest of the company can use rather than each of us having our own silos, but if I do that and you guys all start using it, it will put new demands on the CPU. I might have to buy more licenses from the software vendor. Who's going to pay for that? Does my company have a governance model that says, 'Here's how we tax for it or fund it or….'" It goes like that. You get into all these very interesting things.

Another issue that comes up all the time is the organizational model. How do I organize for SOA? So here we are. BEA is the technology supplier, and we have dialogues that get into, "Can you help me with what other companies have done about governance?" It has nothing to do with the technology, but it is something that they have to wrestle with to take those first steps toward sharing services across the organization—where before they were organized and set up, and their whole governance model was around silos. They had to break those down, and technology is just a part of it. They all have to go at the same rate. If the technology gets too far ahead of the governance, it won't get adopted.